CN116134785A - Low-latency identification of network device attributes - Google Patents

Abstract

A method includes analyzing, by a machine learning model, a first network communication having a first set of inputs. The method further includes exposing, by the machine learning model and based on the analytical reasoning, a device attribute of the first device as a party to the first network communication. The method also includes extracting a first set of important inputs from the machine learning model that have an important impact on determining. The method also includes creating rules for identifying device attributes using the first set of inputs. The rule establishes a condition that, when present in the network communication, implies that a party to the network communication exhibits the device attribute.

Description

Low-latency identification of network device attributes

Background technique

The present disclosure relates to network security, and more particularly, to identifying attributes of devices in network communications.

Network traffic (eg, within a local area network, between separate local area networks, between separate virtual local area networks, and traffic to or from a wide area network) involves sending messages between electronic devices on one or more networks. These electronic devices may include cellular telephones, personal computers, Internet of Things (sometimes referred to herein as "IoT") devices, network infrastructure components, game consoles, computer peripherals, and the like. The large number and variety of electronic devices on a typical network can complicate monitoring traffic on a typical network. This makes it easier for untrusted actors to gain unauthorized access to the network by exploiting network devices that exhibit device vulnerabilities.

Some methods of monitoring network traffic and preventing unauthorized access include establishing rules based, for example, on network addresses where communications originate (e.g., external Internet, specific Internet Protocol addresses, and specific VLANs) or types of communications (e.g., communications respond to established link) to specify whether traffic is allowed to enter (or leave) the network (or virtual local area network). These are often called firewall rules. Firewall rules can reduce the risk of unauthorized access to a network, and the ability to control those devices when sufficient information is available about the organization and population of the network (e.g., what devices/device types exist on the network, and how they are grouped) For example, managing device licenses on a per-device basis). However, some networks are either too large, too simple, or both, to provide this kind of information or control.

In theory, preventing unauthorized network access could also be performed based on known properties of the devices involved in network communications. By analyzing the properties of the network device to which incoming traffic is being directed, or from which outgoing traffic is being sent, a network administrator can determine whether a vulnerable device is engaging in traffic that could put the network at risk . However, devices on some networks are numerous and constantly changing, and some users do not have the skill to recognize those attributes.

Contents of the invention

Some embodiments of the present disclosure may be illustrated as a method that includes analyzing, by a machine learning model, a first network communication having a first set of inputs. The method also includes inferring, by the machine learning model and based on the analysis, that the first device that is a party to the first network communication exhibits device attributes. The method also includes extracting from the machine learning model a first set of significant inputs that are significant to the determination. The method also includes creating a rule for identifying device attributes using the first set of inputs. The rule establishes conditions that, when present in a network communication, imply that a party to the network communication exhibits the device attribute.

Some preferred embodiments of the illustrated method may also include identifying an input weight for each input in the first set of inputs. These preferred embodiments may also include ordering the input weights of the first set of inputs. These preferred embodiments may also include selecting a first significant input set based on ranking.

Some preferred embodiments of the illustrated method may further include analyzing, by the machine learning model, the second network communication having the second set of inputs. These preferred embodiments may also include exposing device attributes by the second device that is a party to the second network communication through the machine learning model and based on analytical reasoning. In these preferred embodiments, extracting may also include identifying an input weight for each input in the second set of inputs, and combining the input weights of the first set of inputs and the second set of inputs.

Some embodiments of the present disclosure may also be illustrated as a system including a processor and a memory in communication with the processor. The memory contains program instructions which, when executed by the processor, are configured to cause the processor to perform a method. A method performed by a processor includes analyzing a first set of network communications having a first set of inputs through a machine learning model. The method performed by the processor also includes reasoning through the machine learning model and based on the analysis that each device is a collection of devices exhibiting device attributes. In this example, each device is a party to network communications in the first set of network communications. The method performed by the processor also includes extracting from the machine learning model a first set of significant inputs that are significant to the determination. The method performed by the processor also includes creating a rule for identifying device attributes using the first set of inputs. The rule establishes a condition that, when present in a set of real-time network communications, implies that a party to the set of real-time network communications exhibits the attribute of the device.

In some preferred embodiments of the illustrated system, the machine learning model is an attention-based model. In these preferred embodiments, said extracting may include identifying, for a particular device in said set of devices, a list of attention weights expressing the importance of each particular input in said first set of inputs for that particular device. Importance of device inference. In these preferred embodiments, the extracting may further include, for a specific input of a specific device, combining attention weights in the list with attention weights of corresponding inputs in the input set of other devices in the device set. This combination may result in a combined weight for that input for all devices in the device set. In these preferred embodiments, extracting may also include comparing the combined weights with other combined weights for other inputs in the set of inputs. In these preferred embodiments, extracting may also include determining that a particular input is a significant input based on the comparison. In these preferred embodiments, extracting may also include adding certain inputs to the first set of significant inputs.

Some embodiments of the present disclosure may also be illustrated as a computer program product comprising a computer-readable storage medium. A computer-readable storage medium has program instructions embodied therewith. The program instructions can be executed by a computer to cause the computer to perform the methods performed by the systems in the above-mentioned embodiments.

In some preferred embodiments of the present disclosure, the program instructions further cause the computer to execute the method performed by the system in the above preferred embodiments.

According to one aspect, there is provided a method comprising: analyzing, by a machine learning model, a first network communication having a first set of inputs; inferring, by the machine learning model and based on the analysis, a A first device exhibits device attributes; extracting from said machine learning model a first set of significant inputs having a significant impact on said determination; and using the first set of inputs to create a rule for identifying device attributes, wherein the rule establishes a condition, the A condition, when present in a network communication, implies that a party to the network communication exhibits device attributes.

According to another aspect, there is provided a system comprising: a processor; and a memory in communication with the processor, the memory containing program instructions configured, when executed by the processor, to cause the processor to perform a method, The method includes: analyzing, by a machine learning model, a first set of network communications having a first set of inputs; inferring, by the machine learning model and based on the analysis, that each device is a set of devices exhibiting device attributes, wherein each device is the a party to a network communication in the first set of network communications; extracting a first set of salient inputs from the machine learning model that have a significant impact on the determination; and using the first set of inputs to create a rule for identifying device attributes, wherein The rule establishes a condition that, when present in a set of real-time network communications, implies that a party to the set of real-time network communications exhibits device attributes.

According to another aspect, there is provided a computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions being executable by a computer to cause all The computer: analyzing, by a machine learning model, a first set of network communications having a first set of inputs; inferring, by the machine learning model and based on the analysis, that each device is a set of devices exhibiting device attributes, wherein each device is the set of devices a party to a network communication in the first set of network communications; extracting a first set of significant inputs from the machine learning model that have a significant impact on the determination; and using the first set of inputs to create a rule for identifying device attributes, wherein The rule establishes a condition that, when present in a set of real-time network communications, implies that a party to the set of real-time network communications exhibits device attributes.

The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

Description of drawings

A preferred embodiment of the invention will now be described, by way of example only, with reference to the following drawings:

FIG. 1 depicts a method of creating and applying a rule set to identify attributes of a device that is a party to network communications, according to an embodiment of the disclosure.

2 depicts a graphical abstraction of a system for developing and applying rule sets to identify attributes of devices that are a party to network communications, according to an embodiment of the disclosure.

3 depicts a method of extracting rules from a machine learning model that is also trained to infer an attribute of a device to infer the attribute, according to an embodiment of the present disclosure.

Figure 4 depicts representative major components of a computer system that may be used in accordance with an embodiment.

While the invention is capable of various modifications and alternative forms, details thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

Detailed ways

Embodiments of the present disclosure relate to network security, and more particularly, to identifying attributes of devices in network communications. While the present disclosure is not necessarily limited to such applications, various embodiments of the present disclosure can be appreciated through a discussion of various examples using this context.

Unauthorized access to certain communication networks (eg, wired LANs, wireless LANs, and VLANs) is sometimes achieved by exploiting security holes in devices authorized for that communication network. Once a specific device (for example, a cell phone model and a security camera model) or device type (for example, an IoT device, a device made by a specific manufacturer, a device with a specific processor brand, and a device running a specific software) is discovered or suspected Vulnerabilities, whether public, in hacker groups, or otherwise, allow unauthorized actors (e.g., cybercriminals) to design intrusion attempts that target those devices or device types. If an unauthorized actor is able to communicate with a vulnerable device on the network, the unauthorized actor may be able to exploit the vulnerability and gain unfiltered access to the vulnerable device. At that point, cybercriminals may be able to take control of the device and use it to gain access to other parts of the network without being detected. In other words, cybercriminals may be able to use a vulnerable device as a conduit to gain unauthorized access to the network as a whole.

For this reason, it is important for individuals maintaining communication networks (also referred to herein as "network administrators," which may include, for example, owners of residential networks and employees/contractors engaged in maintaining enterprise networks) to monitor and filter incoming and outgoing communications. This can be beneficial for incoming and outgoing network traffic from network devices suspected of being compromised. In theory, this is possible by filtering network communications based on attributes of the network devices that are parties to those communications. This may include, for example, filtering traffic from a local area network (also referred to herein as a "LAN") to the Internet, filtering traffic from the Internet into a LAN, filtering traffic between virtual LANs on a LAN (also referred to herein as vLANs), or Filter communication between devices on a single network (such as a single vLAN).

For example, a network administrator may conclude that IoT devices (e.g., smart refrigerators, video doorbells) frequently have outdated, insecure firmware, and therefore may wish to limit the ability of IoT devices to contact (or be contacted by) the Internet. Similarly, some network devices may only need to contact the Internet or other devices on the network for very specific purposes (e.g., time-server synchronization), and thus network administrators may wish to restrict the connection of these devices with time-server Internet addresses ability to communicate. Some specific devices (e.g., specific smartphone models) may be known to be vulnerable to a certain type of attack (e.g., brute-force login attempts), and therefore a network administrator may wish to block repeated attempts to log in to any Internet address on one of those specific devices . Also, some devices may only need to communicate throughout the network for very limited purposes, so network administrators may wish to restrict these devices from communicating with any other network devices for The camera communicates with any storage server on the network, unless the storage server is configured to store footage from that security camera).

However, in order for a network administrator to properly filter network communications based on those device attributes, the attributes of the network devices that are parties to the communication must be known. For very small networks with typically static collections of network devices (for example, home networks and small business networks that do not allow devices not to be owned by businesses on the network), skilled network administrators may be able to monitor device The monitored device filters Internet traffic.

However, many networks do not fall into these categories. For example, the network administrators of many residential networks are often home users who don't even know or know how to identify all the devices on their residential network, let alone identify their attributes or potential vulnerabilities. Similarly, many enterprise-level networks have very large populations of connected devices, populations of connected devices that change significantly over time, or both. Thus, for many networks, maintaining an up-to-date knowledge base of devices on the network, their attributes, and their potential vulnerabilities may be beyond the capabilities of network administrators, and may not even be possible.

To this end, it is of theoretical benefit to automatically and in real-time reason about attributes of network devices that are participants in network communications. This is theoretically possible, for example, by analyzing network communications intended to be received by or sent to those network devices. For example, when a network controller device (e.g., router device, firewall device) detects a communication (e.g., a request to download a set of instructions, such as executable instructions) sent by the network device to an external IP address, the network controller device (sometimes referred to herein as a "network controller," "controller," or "controller device") may analyze the device's traffic and determine that it is an IoT device (eg, a smart water heater). If the external IP address to which the communication is intended to be sent is not associated with the IoT device's manufacturer, the network controller may determine that an unauthorized actor is attempting to install intrusive software on the IoT device and block the communication. By reasoning about the properties of IoT devices in real time, network controllers can prevent unauthorized actors from installing software on devices even if the properties of IoT devices are not known in advance.

However, inferring properties of network devices in real time by analyzing their communications is computationally intensive activity. Typical general-purpose computing devices have historically struggled to do so, and it took a long time, if any, to succeed. However, machine learning models (eg, neural network classifiers, feed-forward networks, recurrent neural networks, long short-term memory networks, and attention-based models) can be trained to accurately reason about device attributes based on the operations of those devices. In some instances, these machine learning models (sometimes referred to herein as "ML models") can be configured to infer device attributes in near real-time. For example, these machine learning models can be trained to analyze historical network communications labeled based on device type, and associate patterns in those network communications with device type labels.

For example, a machine learning model can be fed historical network traffic for a network containing several different device types. The machine learning model can be configured to analyze each communication individually or in combination with other communications and attempt to infer properties of the device from which the communication originated or to which the communication was addressed. These machine learning models can be configured to infer device attributes based, for example, on communication destination, communication origin, communication format, or communication content.

For example, some machine learning models may be configured to analyze DNS names (e.g., ntp.manufacture.com) in DNS queries sent by network devices and, based on those DNS queries, DNS names (also referred to herein as "DNS addresses") ) to reason about device properties. In this way, each communication to a particular DNS name (or names) or a sequence of communications to a particular DNS name (or names) can be considered an input to a machine learning model. Some machine learning models may similarly be configured to analyze actual business content (eg, network bytes of communications) to infer device attributes based on patterns observed in the content of the communications. For example, a smart remote from a particular manufacturer may have a specific signature in requests to update firmware. The actual bytes of these communications can provide input to machine learning models. Thus, machine learning models can be trained to recognize patterns in these inputs and reason about device attributes based on those conditions.

The device attributes that the machine learning model is configured to infer may vary based on the use case for which the machine learning model was trained (eg, capabilities of the network, security concerns of network administrators, population of devices on the network, typical network activity). Some examples of device attributes that a machine learning model can be configured to infer include the operating system of the device, the presence of specific software on the device, the classification of the device (e.g., cellular phone, storage server, IoT device), the manufacturer of the device, the The software version (or the age of the software version) and the age of the device. These device attributes may be specified in tags (eg, metadata) that are appended to historical network communications in the training data. During training of the machine learning model, the inferred device attributes of devices that were a party to historical communications may be compared to actual device attributes in such labels. The configuration of the machine learning model (eg, the weights and biases of the neural network neurons) can then be adjusted based on whether the inferred properties match actual device properties.

Once a machine learning model is sufficiently trained to reason about device attributes based on the business (e.g., by communication event, communication content, communication format), a machine learning model can often infer attributes of network devices involved in the content with sufficient accuracy to address cybersecurity question. Furthermore, where the accuracy of a machine learning model is insufficient, the machine learning model can often be retrained with more historical data (or real-time data) to correct the deficiency. For example, if an ML model can accurately reason that communications are addressed to devices made by a particular company, but cannot accurately reason that communications are addressed by IoT devices, the ML model can be used to either Communications sent by IoT devices on the network for further training.

A typical properly trained machine learning model, while accurate enough to infer properties of a device based on communications sent by or to the device, is computationally intensive. This computational intensity scales the amount of time required for the ML model to reason about device properties. While this computation time may be acceptable for some use cases, applying such ML models to real-time network communications may result in significant and sometimes unacceptable network latency. In use cases where network speed is particularly important, the disadvantage of this network latency may outweigh the benefit of the accuracy with which ML models can reason about device properties.

Therefore, although ML models are theoretically able to help reason about device attributes for the purpose of filtering network traffic, in practice they are not sufficient to quickly provide independent solutions. For the reasons described above, many use cases would benefit from a system that can reason about attributes of network devices based on the communications of those network devices with the accuracy of ML models but without the latency introduced by these models.

Some embodiments of the present disclosure address some of the issues identified above by extracting rules for inferring device attributes from a machine learning model that has been trained to infer device attributes based on the communications of those devices. In some embodiments, these rules are then analyzed for accuracy and, if accurate enough, applied to network traffic in real time. Rules can then be used to analyze real-time network traffic in a computationally easy manner. This analysis can allow rapid inference of attributes of devices involved in those communications, enabling filtering of communications based on device attributes without introducing significant network delays.

For example, some embodiments of the present disclosure may configure a machine learning model (e.g., an attention-based machine learning model) to analyze a collection of network communications and reason about the network devices that were a party to that communication (e.g., the sender of the communication or the intended Receiver) properties. In some embodiments of the present disclosure, the machine learning model may then analyze historical network communications to train the model. These historical communications may be appended with device attribute tags that provide information about the attributes of the network device (or devices) involved in the communication. For example, an attention-based machine learning model may be fed labeled historical communications sent or received by the network for which the attention-based model is being trained. Machine learning models can be trained by augmenting the model when attributes are inferred correctly, but tuning/retraining the model when the attributes inferred by the model do not match the labels.

In some embodiments of the present disclosure, a machine learning model is trained until it is able to infer device attributes with an accuracy sufficient to satisfy the security considerations of the network. After this training process, the ML model can be analyzed to identify the reasoning behind the inferences made by the ML model. In particular, the model can be analyzed to identify important inputs (eg, specific domain names, specific communication formats, specific patterns in message bytes) that are particularly impactful for the ML model's inference of device properties.

In some embodiments, for example, a wrapper such as the LIME wrapper may be applied to a classifier-type machine learning model as it analyzes communications. Such a wrapper can cause the classifier to repeatedly analyze the same set of inputs, but perform small tweaks to the inputs on each iteration. By detecting tweaks that affect the classifier's inferences and tweaks that do not, the wrapper can identify inputs to the classifier that appear to be most important in the inferences made by the classifier for those communications. For example, if the classifier infers that the communication is likely to originate from a device made by a particular manufacturer, the wrapper can infer that the DNS name of the manufacturer's firmware update server is the most important input in that inference.

In some embodiments, rather than a classifier-type ML model (eg, an RNN classifier), an attention-based model may be used to reason about properties of network devices. This can be beneficial because, unlike RNN ML models, the importance of each part of the input with respect to the attention-based model's conclusion can be examined based on the structure of the trained attention-based model. Specifically, the model's attention weights can be used to determine, for a given device attribute, how important each part of network communication is in reasoning about that device attribute. Thus, for attention-based models, no wrapper is needed when identifying important inputs for reasoning about specific device properties. Furthermore, in some embodiments, algorithms can be used to directly analyze attention weights and quickly extract important inputs.

In some embodiments of the present disclosure, rules that can infer properties of a device with or without an ML model can be formulated based on extracted inputs that are particularly important to the ML model's inference of properties of the device. These rules can take the form of formulating conditional statements that can be easily parsed by a computer system (eg, a finite state machine). These conditional statements can specify device properties to reason about whether conditions were found (eg, the content of network communications). For example, in some embodiments, if-then statements may be formulated based on extracted significant inputs. In some such embodiments, the condition of the if-then statement (i.e., the "if" part) can be populated with one or more significant inputs, and the conclusion of the if-then statement (i.e., the "then" part) can be filled with corresponding device properties to populate. For example, if it is determined that a query for the DNS name "ntp.iotproducer.com" is particularly important in classifying a device as an IoT device made by the manufacturer IoTProducer, the corresponding rule could state IF DNSname EQUALS "ntp.iotproducer.com" , then THENdevice=IoT AND devicemanufacturer=IoTProducer.

In some embodiments, these rules can be created manually. For example, a network administrator can examine important inputs to an ML model's reasoning about a device attribute and create if-then rules for that device attribute. In some instances, this may be beneficial, as network administrators may consider device contextual information or recognize the need for complex, multi-condition rules. For example, if a device queries a particular time sync server at least 24 times a day, or if at least 90% of a device's DNS queries are to that specific time sync server, the rule could infer that the device is an IoT device, rather than creating an inference that the Devices are the rules for IoT devices.

However, in some use cases, the number of device attributes for which inference rules are developed may make manual rule creation undesirable or impractical. Therefore, in some embodiments, these rules can be created automatically. For example, an algorithm (e.g., a sliding window algorithm) could consider inputs to the model above a certain weight (e.g., in the 95th percentile) and generate all if-then sequences, where the conditional part (the "if" part ) consists of inputs above that certain weight. These conditions can then be associated with device attributes inferred by the ML model. In other words, inferred properties can be entered into the "then" portion of an if-then statement, creating different combinations of inclusion conditions (e.g., queries on both domain X and domain Y, or queries on either domain A or domain B) and A series of if-then statements for an inferred attribute (eg, a smartphone of a particular manufacturer).

The configuration of such an algorithm may depend on the nature of the machine learning model used to identify important inputs. For example, if a recurrent neural network is trained to reason about device attributes, the algorithm can be configured to analyze the output of a wrapper that identifies key inputs that affect the neural network's conclusions. On the other hand, if an attention-based model is trained to reason about device attributes, the algorithm can be configured to directly analyze the model's attention weights. Inputs with high attention weights (eg, top 5 inputs, inputs with weight above threshold, inputs with weight above percentile) may be identified as important inputs. Either algorithm can then create a proposed set of inference rules based on the identified significant inputs.

In some embodiments, the created inference rules can be tested to measure their accuracy. This is beneficial for confirming that the created rules can accurately reason about desired device properties before relying on the rules in real-time communication. For example, in some embodiments, a rule may be tested on a second set of tagged historical data. Then, the accuracy of the rule can be determined (eg, by computing the f1-score of the rule (f1-score)).

However, in some cases, further historical data may not be available to test the accuracy of the inference rules. Thus, in some embodiments, rules may also be tested on real-time communications. In these embodiments, concurrent reliance on other methods of reasoning or identifying device attributes or filtering of network communications (e.g., manually, using machine learning models, using traditional firewall rules) avoids relying on untested, potentially inaccurate Rules of inference may be useful. In some embodiments, the machine learning model from which the rules are created may also analyze real-time communications, allowing a comparison between the accuracy of the machine learning model and the accuracy of the rules with respect to those communications.

If the rules are determined to be sufficiently accurate, they can be applied to real-time communications by the network controller device without requiring extensive computing resources. For example, rules may be applied in real time using, for example, a general purpose computer on the network or a finite state machine located within a firewall device on the network. Then, when making traffic filtering decisions (e.g., block traffic from the Internet, block traffic between vLANs, etc.), the controller device uses the conclusions of the rules (i.e., the inferred properties of the network device that is party to the analyzed communication ) can then be used by the network controller device.

On the other hand, if inference rules are determined to be inaccurate, they can be reviewed by a network administrator. A network administrator can, for example, compare the accuracy of a rule to the output of an ML model to ensure that the rule reflects the output of the ML model. If the inferences made by the ML model and the network controller device utilizing the rules do not match, the rules may not capture the ML model's decision logic (eg, attention weights). However, if the inferences made by the ML model and the rules match, the ML model may not actually be sufficiently trained. Thus, depending on the results of the review, the network administrator may decide to reconfigure the ML model (e.g., further train the model with new data), reconfigure the rules (e.g., add or remove inputs from the rules, context based on network communication, and other to increase the complexity of the rules) or both.

FIG. 1 depicts a method 100 of creating and applying a rule set to reason about attributes of a device that is a party to a network communication, according to an embodiment of the disclosure. Method 100 may be performed by a computer system, such as computer system 401, that has access to a collection of network communications and a machine learning model configured to analyze those network communications. Method 100 may be performed, for example, by a network controller device embedded in a computer system that also runs a machine learning model (or directs another computer on the network to run a machine learning model).

Method 100 is presented as creating and applying a method for inferring individual device attributes of a device that is a party to one or more network communications (e.g., the device is an IoT device, the device is running a specific OS, the device is running firmware that has not been updated in two years) rule. However, a similar approach can also be applied to create and apply rules for reasoning about multiple device attributes. Similarly, multiple instances of method 100 may be performed to create one or more rules for each device attribute that a network administrator wishes to be able to reason about. For example, if a network administrator wishes to be able to reason about when a party to a network communication is a mobile phone, when a party to a communication is an IoT device, and when a party to a communication is made by a combined insecure device, the method 100 can be performed three times (once for each property).

Method 100 begins at block 102, where a device attribute is selected. The device attributes selected in block 102 may be attributes that a network administrator has identified as important to network security concerns. For example, a network administrator may wish to determine whether devices involved in network communications are running operating systems that are known to be insecure, and filter those network communications accordingly. Similarly, a network administrator may wish to determine whether a device participating in network communications is manufactured by a manufacturer that has a reputation for including insecure firmware in its devices or neglecting to update firmware once the device is manufactured. If the method 100 is being performed for a network where virtually all network clients are company-owned except for employees' personal mobile phones, the network administrator may wish to determine whether the device is a mobile phone. Some network administrators may also wish to determine whether a device is an IoT device, as some network administrators believe that IoT devices are generally insecure.

Once device attributes are selected in block 102, in block 104 a machine learning model can be trained to infer device attributes based on network communications. The machine learning model may be preconfigured to accept network communications as input and output an inference of whether a network device that is a party to the communication exhibits the attribute selected in block 102 . As mentioned earlier, machine learning models can be attention-based models, recurrent neural networks, feed-forward neural networks, or others.

Block 104 may include, for example, receiving a collection of historical communications, where each communication is appended with a tag stating whether the device that was a party to the communication exhibited the selected attribute. For example, if "Is an IoT device" is selected as the device attribute in box 102, the historical data may include a first network communication of a personal computer sending an email to the Internet and a second communication of an IoT light bulb sending a message to the light bulb manufacturer's server . In this example, the first network communication may be appended with a tag indicating that the device that is a party to the communication is not an IoT device (eg, "no", "false", "not IoT"). On the other hand, the second network communication may be appended with a tag indicating that the device party to the communication is an IoT device (eg, "yes", "true", "IoT"). The set of historical communications may be referred to herein as "training data."

In some embodiments, different aspects of historical messages may be included in the training data depending on the desired capabilities of the trained machine learning model or the desired format of the ML model based inference rules. In some embodiments, for example, the domain name to which each message is addressed may be included in the training data. Including domain names may be useful for training a machine learning model to reason about device attributes of a network device based on patterns in the domain names with which the network device communicates. In some embodiments, the content of each communication (ie, the data sent in the communication) may be included in the training data. Content that includes communications may be useful for training machine learning models to reason about device attributes of network devices based on patterns in the devices' network (or Internet) activity. In some embodiments, metadata about the format of the communication (eg, header size, whether the communication uses jumbo packets, whether the message is encrypted, what programming language the message is written in) may be included in the training data. Information about communication formats can be used to train machine learning models to reason about device attributes for network devices based on patterns in which devices (or all devices on a network, such as the same manufacturer or operating system) format network communications in that way. In some embodiments, other aspects of network communications may also be involved.

In some embodiments, block 104 may include purposefully selecting aspects of historical messages to include in the training data based on circumstances (eg, goals of a network administrator). For example, including absolutely all data available and potentially relevant to a collection of network communications can increase the likelihood that the resulting machine learning model will be accurate. However, increasing the size and complexity of the training data may increase the time required to train the ML model and the time required (and the difficulty of extraction) to extract the most important inputs for the ML model's inference. Therefore, in use cases where speed and ease of training and rule creation are particularly important, overinclusiveness can be detrimental. As another example, including only aspects of historical communications that are directly related to the desired rule type (such as inferring device attributes based on patterns in domain names queried by the device) can increase the speed at which ML models are trained and the ML models trained based on Likelihood of expecting an input to make an inference about. However, excluding data from machine learning training can reduce the accuracy of the final trained model. Similarly, excluding data from a model can reduce the likelihood that useful context is included in rules created from a trained ML model.

Block 104 includes using the training data to train the machine learning model once the training data is selected. For example, a labeled network communication (or collection of communications) can be input into a machine learning model, and the machine learning model can provide inferences about whether a network device that is a party to that communication (or communications) exhibits that the ML model is configured to make The output of its inferred device properties. Early in the training process, ML models may frequently make incorrect inferences, causing the model to be retrained (including, for example, adjusting bias or attention weights). Then, the same network communication or a new network communication can be input to the ML model again.

When training the ML model in block 104 (or after the ML model is deemed sufficiently trained), the controller device may determine in block 106 whether the model is accurate enough for the purpose of the network. In some embodiments, for example, the computer system of the supervisory method 100 may monitor the developing accuracy of the ML model as it is trained in block 104 and compare the accuracy consistently to a desired accuracy threshold. This may be beneficial because it may enable the computer system to stop the training process in block 104 as soon as the ML model is sufficiently trained, thereby avoiding unnecessary time and resources spent on overtraining the model on the training data. In some embodiments, the training process in block 104 may be stopped periodically, allowing the accuracy of the ML model to be checked in block 106 . This can involve, for example, testing the ML model on previous training data or new training data. Testing the ML model with new training data can be beneficial because it prevents the ML model from being overtrained on previous training data without being flexible enough to make accurate inferences on other training data (or real-time data).

The precise metric used to measure the accuracy of the ML model can be chosen based on the environment and network administrator preferences. Some examples include raw accuracy (e.g., total correct inferences divided by total inferences), model precision (e.g., correct positive inferences divided by total positive inferences, correct negative inferences divided by total negative inferences), recall (e.g., true Positive inferences divided by the sum of true positive inferences and false negative inferences), and the F1 score (combined precision and recall).

If it is determined in block 106 that the machine learning model is not accurate enough, the computer system (or network administrator) overseeing method 100 may return to block 104 to continue training the machine learning model. In some embodiments, this may simply involve uninterrupting the training process, allowing continuous training of the ML model. However, in some embodiments, such as those in which the training process was interrupted at block 106, returning to block 104 may include adding new training data to the training process, which may increase the flexibility of the ML model.

However, if in block 106 it is determined that the machine model is sufficiently accurate, the computer system of supervisory method 100 may proceed to block 108 where significant inputs to the inference of the ML model are extracted. As previously mentioned, the particular process performed in block 108 may depend on the structure of the machine learning model, the nature of the training data, and preferences regarding the inference rules to be created from significant inputs.

For example, if the machine learning model trained in block 104 is a recurrent neural network, block 108 may include applying a wrapper such as the LIME wrapper to the ML model to monitor various calls to the ML model's input and inference in the ML model on the impact. On the other hand, if the machine learning model trained in block 104 is an attention-based model, then block 108 may simply involve querying the attention weights applied to each input of the ML model.

Furthermore, if the training data used to train the ML model in block 104 is complex, the important inputs extracted at block 108 may take various forms. For example, if an ML model is trained on all available data related to a collection of network communications, the extracted inputs may include any of that data (e.g., the recipient of the communication, the time of the communication, how often the communication was sent, the format, etc.). On the other hand, if the ML model is trained only on DNS names queried by networked devices, the extracted input will only include the DNS name (or DNS names) that are influential in inferring whether the device exhibits the device attribute.

In some instances, significant inputs may be inputs that, when identified by the ML model, cause the ML model to infer certain device attributes based solely on that input. For example, an important input could take the form of a domain name, and if queried by a network device, the ML model infers that the device is an IoT device. In some cases, however, an important input may be one that causes the ML model to infer specific device properties only if that important input is identified along with other inputs. For example, in some cases an important input may be a series of bytes in the header of a network communication. When identified in isolation, the sequence of bytes may not be sufficient to create inferences about device properties. However, when the ML model identifies a series of bytes that it also identified as a second series of bytes in a second network communication from the same network device on the same day, the ML model may be able to accurately reason about device attributes of the network device.

Furthermore, implementation preferences of network administrators may also affect the important inputs extracted in block 108 . In some use cases, for example, network administrators may wish to extract only the most important inputs for rule creation. On the other hand, in some use cases, a network administrator may wish to extract the five most important inputs.

The inferred device properties may also affect inputs determined to be important. An input that may be particularly useful to infer that the device is an IoT device may be quite different from an input that may be useful to infer that the device is a device made by a particular manufacturer or to infer that the device is a personal mobile phone.

In some embodiments, extracting important inputs may also include extracting weights that numerically represent the importance of the inputs to the inference of the ML model. For example, if the ML model trained in block 104 is an attention-based model, each important input extracted may also be appended with an attention weight for that input.

Thus, if a machine learning model is trained at block 104 to analyze the set of DNS names queried by network devices, the significant input extracted at block 108 may take the form of the following list: (1) Since ten DNS names are in the input data exist, so they are most influential in the inference of the ML model; and (2) for each of the ten DNS names, the numerical weight applied to that DNS name.

Once significant inputs are extracted in block 108 , a set of inference rules is created in block 110 based on these extracted inputs. As mentioned earlier, these inference rules can take the form of if-then statements containing a condition and a conclusion (inference here) based on that condition. For example, a rule created could take a rule with conditions "if 'DNS name' equals 'ntp.manufacturer.com' and 'device-metrics-us.manufacturer.com' and conclusion "then 'devicemanufacturer' equals 'manufacturer.'" The form of a statement. This rule, when parsed by a computer (such as a general-purpose computer system or a finite state machine), will conclude that when a network device queries "ntp.manufacturer.com" and "device-metrics-us.manufacturer.com" , the device is manufactured by a "manufacturer".

In some embodiments, the inference rules created at block 110 may be created manually (eg, by a network administrator) or automatically. In use cases with simple, short sets of extracted significant inputs, automatic rule creation can result in a manageable set of rules. For example, if the first three DNS names were extracted at block 108, block 110 may include automatically incorporating each of these DNS names into a rule that asserts that if a single DNS name exists, then exhibit device attributes. Block 110 may also include an AND operator (resulting in a condition requiring two names), an "OR" operator (resulting in a condition requiring one or two DNS names), and an exclusive OR (XOR) operator. )" operator (resulting in the condition that a DNS name is required but one DNS name is not satisfied if two DNS names exist)" operator (resulting in the condition that one DNS name is not satisfied if two DNS names exist) In some embodiments, all three DNS names may be combined into one condition, such as a condition that requires the first two DNS names but requires the absence of the third DNS name. The resulting set or inference rules may include 25 rules or less so that selecting the exact inference rule (or rules) is manageable.

In some embodiments, the extracted inputs may allow for the creation of more complex inference rules. For example, if the important inputs extracted at block 108 include timestamps of network communications, the rules created at block 110 may utilize these timestamps. For example, rules can be created that include conditions for a network device to send traffic to an IP address between certain time periods (for example, between 2 am and 4 am) or at a certain frequency (for example, at least 40 times per day) . In embodiments where most or all data related to network communications is included in the training data, the extracted inputs may allow for even more complex rules. For example, a sequence mining algorithm such as the PrefixSpan algorithm may collect event sequences in the significant input extracted at block 108 . These rules may be based, for example, on a series of communications sent to a particular sequence of destinations, or a series of communications sent with a particular sequence of content.

In some use cases, a network administrator may prefer to prevent the initial set of rules created at block 110 from being too complex. This can potentially avoid unnecessary rule testing and analysis in later blocks of method 100 . To this end, block 110 may default to first creating simple rules (eg, simple if-then statements). In some embodiments, it may also be preferred that rules are created or reviewed by a network administrator. Network administrators are able to identify context within inputs that rule creation algorithms do not. To this end, the network administrator may be able to eliminate rules that the network administrator has reason to believe will be inaccurate, even if they were created with significant input (e.g., a request that a device query both a manufacturer's ntp server and a competing manufacturer's ntp server rule).

After creating the set of inference rules in block 110 , in block 112 the rules can be tested for accuracy. In some embodiments, testing the inference rules may include applying the inference rules to new data sets using a computer system, such as a general purpose computer processor. For example, a computer may load an inference rule into memory, receive new network communications, and compare that network communication to the text in the "conditions" of the inference rule. If the data in the network communication matches the condition, the computer will infer that the device that is a party to the communication exhibits that device attribute. For example, if the condition is "DNS name=ntp.smarttoaster.com", and the network communication is a query to ntp.smarttoaster.com, the computer will conclude that the device (here, the sending device) that is the party to the communication presents the device properties (for example, the device is a smart toaster).

Using the new data set rather than the previous training data in block 112 can beneficially reduce the likelihood that the rules are well suited to the previous historical training data and less suitable for making inferences based on data different than the previous historical training data. In other words, by testing the created inference rules on new data, the method 100 can prevent the data from being "overtrained" to previous historical training data. In some embodiments, a mixture of new data and old training data (eg, 80% old training data, 20% new data) may be used to test the rules.

The new data used in block 112 may take the form of a second set of historical training data or real-time data from real-time communications in the network. If a second set of historical training data is used, the computer's conclusions from applying the second set of training data to the rules it creates may be able to compare its inferences to the labels in the training data, or to the ML trained on the second set of training data. The inference of the model is compared. However, it may also be particularly beneficial to analyze the new data set using the machine learning model trained in block 104 if the real-time data is used for the new data set, since the real-time data will not likely be labeled. Then, for accuracy purposes, the inferences of the computer running the inference rules and the machine learning model can be compared.

In some embodiments, determining whether the created inference rules are sufficiently accurate in block 112 may include performing an accuracy calculation similar to that performed on the trained ML model in block 106 . For example, raw accuracy, precision, recall, F1 score, or a combination thereof can be calculated for each created rule. These measurements may then be compared to one or more accuracy thresholds (eg, precision thresholds, F1 score thresholds) in block 112 .

If it is determined in block 112 that the rules are not sufficiently accurate, then in block 114 the rules are reviewed. In some embodiments, block 114 may involve human reviewers (eg, network administrators) analyzing the rules for error sources. For example, a human reviewer can review a rule for potential parsing errors. Human reviewers may also review context within the training data that may explain inaccuracies or be useful in avoiding inaccuracies. Human reviewers may review significant input extracted at block 108 (eg, input based on the content of network communications likely to be found in nearly all communications on the network) for potential errors.

In some instances, review of the rules at 114 may indicate that the rules can be improved. For example, if the rule created at block 110 takes the form of an if-then statement that infers device attributes if communications are sent to a particular DNS name, and if block 112 determines that the rule results in an unacceptable number of false positive references, then at block 112 Reviewing the rules at 114 may reveal that the context added from the training data suggests modifying the rules to reason about device attributes if communications are sent to a particular DNS name at least 6 times within 24 hours. This can be achieved by increasing the complexity of the rule creation algorithm (e.g., moving from a simple algorithm that inserts a field into an if-then rule) to account for communication timing, the impact of other network communications, the sequence between communications (e.g., the PrefixSpan algorithm), or All of the above are more complex algorithms to implement the modification rules. Modifying the rules at block 114 may also be performed by a human reviewer, such as a network administrator.

In some cases, the determination that a rule is inaccurate in block 112 may be because the machine learning model on which the rule is based (or an important input on which the rule is based) is inaccurate for the new data used in block 112 . In these cases, method 100 may include returning from block 114 to block 104, at which point the machine learning model may then be retrained. However, in most cases, performing 104 in block 106 with a sufficiently large training set and setting the accuracy threshold appropriately high should prevent inaccuracies at block 112 due to poorly trained networks. To this end, block 114 will generally proceed to block 112, and is shown here as such.

After reviewing and modifying the rules, block 112 again determines whether the rules are sufficiently accurate. This subsequent iteration of block 112 may involve the same analysis as previously discussed. If block 112 determines that the rule is sufficiently accurate, the rule is applied in block 116 . In some embodiments, block 116 may involve adding the created rule to a list of "accepted" rules for later potential application to real-time network traffic. In some embodiments, block 116 may include applying the rules to the real-time live data. As already discussed, this can be performed by a general purpose computer having a processor configured to compare live network traffic to the conditions of the created rules (eg, using string comparisons). For most rules created, a simple finite state machine is probably sufficient for this comparison. When these rules are applied to real-time network traffic, inferences based on these rules can be used in making manual or automatic traffic filtering decisions (e.g., whether to block traffic to IoT devices or prevent devices with vulnerable operating systems from contacting managed networks). VLANs of controller devices or VLANs with sensitive storage are used when making decisions. In some embodiments, this rule application may be performed, for example, on a network firewall device or router device.

For ease of understanding, FIG. 2 depicts a graphical abstraction 200 of a system for developing and applying rule sets to reason about attributes of devices that are a party to network communications, according to an embodiment of the present disclosure. The purpose of Figure 2 is to provide a simplified view of the inputs and outputs of the process of the present disclosure. Thus, the components and processes suggested by graphical abstraction 200 are simplified abstractions and are not intended to be precise representations of embodiments of the present disclosure.

In graphical representation 200, a collection of network communications 202 is input into a machine learning model 204 to train the machine learning model to infer device attributes for devices that are a party to those network communications. In some embodiments, this device attribute will have been selected previously, and the content of network communication 202 will have been selected for those training purposes. Accordingly, network communication 202 may contain tags that imply whether a party to the communication exhibits device attributes. The content of network communication 202 may be selected to target logical inference of inferences made by machine learning model 204 . For example, if the network administrator wishes to train the machine learning model 204 to make inferences based on the actual bytes of the network communication rather than, for example, information about the sender or intended recipient, the network communication 202 may be reduced to contain only the content of the message, while Not any additional communication data.

Once machine learning model 204 is properly trained to infer device attributes based on network communications 202 , machine learning model 204 itself is analyzed by computer system 206 . Computer system 206 may be any computer capable of analyzing machine learning model 204 to extract inputs that are meaningful in the inferences made by machine learning model 204 . For example, if machine learning model 204 is a recurrent neural network, computer system 206 may be a system with a processor capable of running a LIME wrapper. If the machine learning model 204 is an attention-based network, the computer system 206 may be a system having a processor capable of identifying and ranking the attention weights of the machine learning model 204 . In some embodiments, computer system 206 may be a computer system residing on a network responsible for managing network communications (eg, a network controller device or a computer running network controller software).

Computer system 206 can then create inference rules 208 based on the extracted significant inputs. In some embodiments, computer system 206 may, for example, utilize a single algorithm capable of taking input and formulating inference rules 208 (shown here as a list of five conditions on the left and a corresponding list of five inferences on the right). This can be beneficial when extracting important inputs from attention-based models, since attention weights can be easily accessible to algorithms specialized for rule creation. In some embodiments, the rule creation algorithm may also obtain the extracted significant inputs from a separate wrapper applied to the neural network 204 .

Once inference rules 208 are created, computer system 212 applies them to new sets of network communications 210 . In some embodiments, the new set of network communications 210 may be an additional set of training data for the purpose of validating the inference rules 208 . In other embodiments, the new set of network communications 210 may be live, real-time network traffic. In some embodiments, computer system 212 may be the same computer system as computer system 206 (eg, a network controller device) or a different computer system. In some embodiments, computer system 212 may be any computer system capable of performing string comparisons between conditions in inference rules 208 and sets of network communications 210 .

Computer system 212 may output inference 214 . As shown, inference 214 shows that computer system 212 has found that two conditions (i.e., a first condition and a fourth condition) are satisfied, and therefore it can be inferred that a device that is a party to network communication 210 exhibits a corresponding first condition. and a fourth device property. As presented, Figure 2 shows an example where two device attributes are inferred. For example, computer system 212 may infer that the device that is a party to network communication 210 is an IoT device (eg, first condition) with firmware that is more than one year old (eg, fourth condition). However, in some embodiments of the invention, only one device attribute per set of rules may be inferred.

As has been discussed previously, extracting important inputs and creating rules based on those inputs can vary based on circumstances (eg, ML model properties, network administrator preferences). For this reason and for understanding, FIG. 2 is presented as an example method 300 of extracting rules from an ML model to infer attributes of a device that is also trained to infer the attributes, according to an embodiment of the present disclosure. Method 300 may be performed by a computer system, such as computer system 401, configured to monitor and control network communications on a network (eg, a network controller device or a system hosting network controller software).

Method 300 begins at block 302, where an attention model machine learning model is trained to infer whether a device participating in one or more network communications exhibits preselected device attributes based on those network communications. Details of block 302 can be found in this disclosure. Specific examples can be found with respect to block 104 of FIG. 1 and machine learning model 204 of FIG. 2 . Once the attention-based model is trained in block 302 , input extraction begins in block 304 .

In block 304, devices that are inferred by the attention-based model are identified. For example, each set of communications analyzed by an attention-based model in the dataset can be assigned a unique hypothetical network device. For each set of communications for which the attention-based model infers that there are pre-selected attributes, in block 304 a hypothetical device may be added to a list of "recognized" devices. For example, if the attention model analyzes 10 communication sets, and infers that a preselected attribute (e.g., IoT device) is present in 5 of those sets, block 304 may result in identifying the exhibited preselected attribute (here, 5 unique devices that are properties of IoT devices). This is true even if the actual network from which the 10 communication sets originate consists of only two devices, only one of which is an IoT device. For the purposes of method 300, it may be sufficient to consider each set of communications as corresponding to a unique device.

For each device (eg, each imaginary device) identified in block 304 , an attention weight assigned to each input (eg, header of the communication, address to which the communication is sent) is identified in block 306 . In other words, for each set of communications, block 306 determines the relevance of each aspect of the communications based on an inference that the corresponding device exhibits the preselected attributes. In attention-based models, these attention weights take the form of numerical expressions of the importance applied to each input, and can be derived directly from the structure of the model. Accordingly, block 306 may take the form of extracting those attention weights directly from the model for each device identified in block 304, resulting in a list of attention weights for each identified device. For example, in some embodiments, the list may take the form of a list of DNS names to which communications in the set of communications were sent, and for each DNS name, a number representing the impact of the DNS name's presence on the inference.

In block 308, for each device, the attention weights identified in block 306 are summed. For example, if 5 devices are identified in block 304, and if the attention-based model has attention weights of 0.2, 0.1, 0.3, and 0.2 for the DNS name firmware_fetch.manufacturer.com, respectively, for the 5 devices, block 308 may These attention weights are comprised of adding together, resulting in a combined weight of 0.9 for the DNS name firmware_fetch.manufacturer.com for the set of identified devices. This summation process can be repeated for each input for which attention weights are available. For example, if the data on which the attention model is trained contains queries for 30 DNS names, block 308 may produce a list of 30 combined weights. Each of these combined weights will represent the total attention weight given to that DNS name across all 5 identified devices.

Once the combined weights are created in block 308 , the combined weights are ordered in block 310 . This may include, for example, sorting the combination weights in descending order. In other words, the largest combination weights will be listed first and the smallest combination weights will be listed last. Because each combined weight corresponds to the sum of the weights of the individual inputs on all devices identified in block 304, the result of block 310 provides the most influential input for attention-based model inference on all identified devices list.

Using the ranked list of combined attention weights, in block 312 the computer system can create inference rules based on the most influential inputs. For example, an algorithm could automatically obtain the 5 most influential inputs and insert them into a simple if-then statement whose "if" condition is the presence of the influential input and whose "then" condition is the inference of the device properties . As previously mentioned, in some embodiments, these created rules may be more complex and contain more context (e.g., two sorted inputs are required to be present to create device attribute inferences, inputs are required to be present at least X times within a Y time period , requires a specific input sequence). The rules created as part of method 300 can then be tested for accuracy by any of the methods discussed herein. If accurate, the rules created can be applied to real-time network traffic.

FIG. 4 depicts representative major components of an example computer system 401 that may be used in accordance with embodiments of the present disclosure. The specific components described are presented for purposes of illustration only, and are not necessarily the only such variations. Computer system 401 may include processor 410 , memory 420 , input/output interface (also referred to herein as I/O or I/O interface) 430 and main bus 440 . Main bus 440 may provide a communication path for other components of computer system 401 . In some embodiments, main bus 440 may connect to other components such as a dedicated digital signal processor (not shown).

Processor 410 of computer system 401 may include one or more CPUs 412. Processor 410 may additionally include one or more memory buffers or caches (not shown) that provide CPU 412 with temporary storage of instructions and data. CPU 412 may execute instructions on input provided from cache or from memory 420 and output results to cache or memory 420. CPU 412 may include one or more circuits configured to perform one or more methods consistent with embodiments of the present disclosure. In some embodiments, computer system 401 may contain multiple processors 410 typical of relatively large systems. However, in other embodiments, computer system 401 may be a single processor with a single CPU 412.

Memory 420 of computer system 401 may include a memory controller 422 and one or more memory modules (not shown) for temporary or permanent storage of data. In some embodiments, the memory 420 may include a random access semiconductor memory, a storage device, or a storage medium (volatile or non-volatile) for storing data and programs. A memory controller 422 may communicate with processor 410 to facilitate storage and retrieval of information in the memory modules. Memory controller 422 may communicate with I/O interface 430 to facilitate storage and retrieval of input or output in the memory modules. In some embodiments, the memory module may be a dual in-line memory module.

I/O interfaces 430 may include I/O bus 450 , terminal interface 452 , storage interface 454 , I/O device interface 456 , and network interface 458 . I/O interface 430 may connect host bus 440 to I/O bus 450 . I/O interface 430 may direct instructions and data from processor 410 and memory 420 to various interfaces of I/O bus 450 . I/O interface 430 may also direct instructions and data from various interfaces of I/O bus 450 to processor 410 and memory 420 . The various interfaces may include a terminal interface 452 , a storage interface 454 , an I/O device interface 456 , and a network interface 458 . In some embodiments, various interfaces may include a subset of the above interfaces (eg, an embedded computer system in an industrial application may not include terminal interface 452 and storage interface 454).

Logic modules throughout computer system 401—including but not limited to memory 420, processor 410, and I/O interface 430—may communicate faults and changes to one or more components to a hypervisor or operating system (not depicted). A hypervisor or operating system may allocate the various resources available in the computer system 401 and keep track of the location of data in memory 420 and the locations of processes assigned to the various CPUs 412. In embodiments where elements are combined or rearranged, aspects of the capabilities of the logic modules may be combined or redistributed. These variations will be apparent to those skilled in the art.

The invention may be a system, method and/or computer program product at any possible level of integration of technical details. A computer program product may include a computer readable storage medium (or multiple media) having computer readable program instructions thereon for causing a processor to perform aspects of the invention.

A computer readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example and without limitation, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskette, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, or flash memory) ), static random access memory (SRAM), portable compact disc read only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, such as punched cards on which instructions are recorded, or embossed in grooves Structured mechanical encoding devices, and any suitable combination of the above. Computer-readable storage media, as used herein, should not be interpreted as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., pulses of light through fiber optic cables) , or electrical signals transmitted through wires.

Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing/processing device, or via a network, such as the Internet, local area network, wide area network, and/or wireless network, to an external computer or external storage device. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or in the form of a or any combination of multiple programming languages (including object-oriented programming languages such as Smalltalk, C++, etc.) and procedural programming languages (such as the "C" programming language or similar programming languages). The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server to execute. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or can be connected to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, in order to carry out aspects of the invention, electronic circuitry including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may be programmed by utilizing computer-readable program instructions that state the information to execute computer readable program instructions to personalize electronic circuits.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine such that instructions executed via the processor of the computer or other programmable data processing apparatus create a process for implementing the flowchart and/or block diagram means for the function/action specified in one or more blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct a computer, a programmable data processing device, and/or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes the , the article of manufacture includes instructions for implementing aspects of the functions/acts specified in one or more blocks of the flowchart and/or block diagrams.

Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device or other equipment, so that a series of operation steps are executed on the computer, other programmable device or other equipment to produce a computer-implemented process, such that Instructions executed on computers, other programmable devices, or other devices implement the functions/actions specified in one or more blocks of the flowcharts and/or block diagrams.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed as one step, executed concurrently, substantially concurrently, with some or all of the time overlapping, or the blocks may sometimes be executed in the reverse order, depending upon the steps involved. Function. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special-purpose hardware and computer instructions that perform the specified functions or actions, or combinations of special-purpose hardware and computer instructions. hardware system to achieve.

The description of various embodiments of the present disclosure has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to explain the principles of the embodiments, practical applications or technical improvements to the market, or to enable other ordinary skilled in the art to understand the embodiments disclosed herein.

Claims (21)

1. A method comprising: analyzing a first network communication having a first set of inputs by a machine learning model; exposing device attributes by the machine learning model and based on the analytical reasoning that the first device that is a party to the first network communication; extracting from the machine learning model a first set of significant inputs having a significant impact on the determination; and A rule for identifying the device attribute is created using the first set of inputs, wherein the rule establishes a condition that, when present in a network communication, implies that a party to the network communication exhibits the device attribute. 2. The method of claim 1, wherein said extracting comprises: identifying an input weight for each input in the first set of inputs; sorting the input weights of the first set of inputs; and The first significant input set is selected based on the ranking. 3. The method of claim 2, further comprising: analyzing a second network communication having a second set of inputs by the machine learning model; and exposing the device attribute by the machine learning model and based on the analytical inference by the second device that is a party to the second network communication; Wherein said extraction also includes: for each input in the second set of inputs, identifying an input weight; and The input weights of the first set of inputs and the second set of inputs are combined. 4. The method of claim 1, wherein the machine learning model is an attention-based model. 5. The method of claim 1, wherein the rule is an if-then statement. 6. The method of claim 1, further comprising: applying said rules to real-time network communications; detecting said condition in said real-time network communication; inferring, based on the detection, that a second device participating in the real-time network communication exhibits the device attribute; and The real-time network communication is blocked based on the identification. 7. The method of claim 1, wherein the first set of significant inputs includes domain names. 8. A system comprising: processor; and memory in communication with the processor, the memory containing program instructions that, when executed by the processor, are configured to cause the processor to perform a method comprising: analyzing a first set of network communications having a first set of inputs by a machine learning model; inferring by the machine learning model and based on the analysis that each device is a set of devices exhibiting device attributes, wherein each device is a party to a network communication in the first set of network communications; extracting from the machine learning model a first set of significant inputs having a significant impact on the determination; and Creating a rule for identifying attributes of the device using the first set of inputs, wherein the rule establishes a condition that, when present in a set of real-time network communications, implies that a party to the set of real-time network communications exhibits the device Attributes. 9. The system of claim 8, wherein the machine learning model is an attention-based model, and wherein the extracting comprises: identifying, for a particular device in the set of devices, a list of attention weights expressing the importance of each particular input in the first set of inputs to reasoning for the particular device; combining, for a particular input of said particular device, said attention weights in said list with said attention weights for corresponding inputs in said set of inputs for said other devices in said set of devices, resulting in combined weights for the inputs corresponding to all devices in the set of devices; comparing the combined weight with other combined weights for other inputs in the set of inputs; determining that the particular input is a significant input based on the comparison; and The particular input is added to the first significant input set. 10. The system of claim 9, wherein the specific input for the specific device is a DNS name queried by the device, and wherein the corresponding inputs for the other devices in the set of devices are those other The DNS name that the device queries. 11. The system of claim 10, wherein the rules include inferring that a network device exhibits the device attribute if the network device queries the DNS name. 12. The system of claim 8, wherein the rules include inferring that a network device exhibits the device attribute if the network device queries the DNS name and the second DNS name. 13. The system of claim 8, wherein the first set of significant inputs comprises specific byte sequences in real-time network communications. 14. The system of claim 8, wherein the first set of significant inputs includes DNS names, and the condition includes querying the DNS names at least a threshold number of times within a specified time period. 15. A computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by a computer to cause the computer to: analyzing a first set of network communications having a first set of inputs by a machine learning model; inferring, by the machine learning model and based on the analysis, that each device is a set of devices exhibiting device attributes, wherein each device is a party to a network communication in the first set of network communications; extracting from the machine learning model a first set of significant inputs having a significant impact on the determination; and Creating a rule for identifying attributes of the device using the first set of inputs, wherein the rule establishes a condition that, when present in a set of real-time network communications, implies that a party to the set of real-time network communications exhibits the device Attributes. 16. The computer program product of claim 15, wherein the machine learning model is an attention-based model, and wherein the extracting comprises: identifying, for a particular device in the set of devices, a list of attention weights expressing the importance of each particular input in the first set of inputs to reasoning for the particular device; combining, for a particular input of said particular device, said attention weights in said list with said attention weights for corresponding inputs in said set of inputs for said other devices in said set of devices, A combined weight for the input corresponding to all devices in the set of devices results. 17. The computer program product of claim 16, wherein the specific input for the specific device is a DNS name queried by the device, and wherein the corresponding input for the other devices in the set of devices is The DNS names that those other devices look up. 18. The computer program product of claim 15, wherein the rules include inferring that a network device exhibits the device attribute if the network device queries the DNS name. 19. The computer program of claim 15, wherein the rule includes inferring that a network device exhibits the device attribute if the network device queries the DNS name and the second DNS name. 20. The computer program of claim 15, wherein the first set of significant inputs includes DNS names, and the condition includes querying the DNS names at least a threshold number of times within a certain period of time. 21. A computer program comprising program code means adapted to perform the method of any one of claims 1 to 7 when said program is run on a computer.

Images