Low-latency identification of network device properties

Abstract

The method includes analyzing a first network communication with a first set of inputs using a machine learning model. The method also includes inferring, using the machine learning model, based on the analysis, that a first device involved in the first network communication exhibits a device property. The method also includes extracting from the machine learning model a first set of significant inputs that significantly influenced the determination. The method also includes creating rules for identifying the device property using the first set of inputs. The rules establish conditions that, when present in the network communication, suggest that a party to the network communication exhibits the device property.

Description

[Technical Field]

[0001] The present disclosure relates to network security, and more particularly to identifying properties of devices in network communications. [Background technology]

[0002] Network traffic (e.g., traffic within a local area network, between separate local area networks, between separate virtual local area networks, and between wide area networks) involves the transmission of messages between electronic devices on one or more networks. These electronic devices may include mobile phones, personal computers, Internet of Things (sometimes referred to herein as "IoT") devices, network infrastructure components, game consoles, computer peripherals, etc. The vast 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 exploit network devices that exhibit device vulnerabilities and gain unauthorized access to the network.

[0003] Some methods of monitoring network traffic and preventing unauthorized access include establishing rules that determine whether communications are allowed to or from a network (or virtual area network) based, for example, on the network address from which the communications originate (e.g., the external Internet, specific Internet Protocol addresses, and specific virtual local area networks) or the type of communication (e.g., whether the communication is in response to an already established link). These are commonly referred to as firewall rules. Firewall rules can reduce the risk of unauthorized access to a network when sufficient information about the network's organization and number (e.g., the devices / device types on the network and how they are grouped) and the ability to control those devices (e.g., managing device permissions on a per-device basis) are available. However, some networks are too large, too simple, or both to provide this information or control.

[0004] Preventing unauthorized network access could theoretically be based on known properties of devices involved in network communications. By analyzing the properties of network devices to which incoming communications are sent or from which outgoing communications are sent, network administrators can determine whether vulnerable devices that could compromise the network are participating in the communications. However, the number of devices on some networks is so large and constantly changing that some users may not have the expertise to identify their properties. Summary of the Invention

[0005] Some embodiments of the present disclosure may be described as a method including analyzing a first network communication with a first set of inputs using a machine learning model. The method also includes inferring, based on the analysis by the machine learning model, that a first device involved in the first network communication exhibits a device property. The method also includes extracting from the machine learning model a first set of significant inputs that significantly influenced the determination. The method also includes creating rules for identifying the device property using the first set of inputs. The rules establish conditions that, when present in the network communication, suggest that a party to the network communication exhibits the device property.

[0006] 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 ranking the input weights of the first set of inputs. These preferred embodiments may also include selecting a first set of significant inputs based on the ranking.

[0007] Some preferred embodiments of the illustrated method may also include analyzing the second network communication with the second set of inputs using a machine learning model. These preferred embodiments may also include inferring, based on the analysis using the machine learning model, that a second device involved in the second network communication exhibits a device property. In these preferred embodiments, the extracting step may further include identifying an input weight for each input in the second set of inputs and combining the input weights of the first and second sets of inputs.

[0008] Some embodiments of the present disclosure may also be described as a system including a processor and a memory in communication with the processor. The memory includes program instructions configured, when executed by the processor, to cause the processor to perform a method. The method performed by the processor includes analyzing a first network communication set with a first set of inputs using a machine learning model. The method also includes inferring, based on the analysis using the machine learning model, that each device in the device set exhibits a device property. In this example, each device is a party to network communications in the first network communication set. The method also includes extracting from the machine learning model a first set of significant inputs that significantly influenced the determination. The method also includes creating a rule for identifying the device property using the first set of inputs. The rule establishes a condition that, when present in the real-time network communication set, suggests that a party to the real-time network communication set exhibits the device property.

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

[0010] Some embodiments of the present disclosure may also be manifested as a computer program product including a computer-readable storage medium having program instructions embodied therein that are executable by the computer to cause the computer to perform the methods performed by the system in the above-described embodiments.

[0011] In some preferred embodiments of the present disclosure, the program instructions also cause a computer to perform the methods performed by the system in the preferred embodiments described above.

[0012] According to one aspect, a method is provided that includes analyzing, with a machine learning model, a first network communication with a first set of inputs; inferring, with the machine learning model, based on the analysis, that a first device that is a party to the first network communication exhibits a device property; extracting from the machine learning model a first set of significant inputs that significantly influenced the determination; and creating rules for identifying the device property using the first set of inputs, the rules establishing conditions that, when present in the network communication, suggest that a party to the network communication exhibits the device property.

[0013] According to another aspect, a system is provided that includes a processor and a memory in communication with the processor, the memory including program instructions configured, when executed by the processor, to cause the processor to perform a method comprising: analyzing, with a machine learning model, a first network communication set with a first set of inputs; inferring, with the machine learning model, based on the analysis, that each device in the device set exhibits a device property, where each device is a party to network communications in the first network communication set; extracting from the machine learning model a first set of significant inputs that had a significant influence on the determination; and creating rules for identifying the device property using the first set of inputs, the rules establishing conditions that, when present in the real-time network communication set, suggest that a party to the real-time network communication set exhibits the device property.

[0014] According to another aspect, a computer program product is provided that includes a computer-readable storage medium having program instructions embodied thereon, the program instructions causing a computer to analyze, with a machine learning model, a first network communication set with a first set of inputs; infer, with the machine learning model, based on the analysis, that each device in the device set exhibits a device property, where each device is a party to network communications in the first network communication set; extract from the machine learning model a first set of significant inputs that had a significant influence on the determination; and create rules using the first set of inputs to identify the device property, where the rules are executable by a computer to establish conditions that, when present in the real-time network communication set, suggest that a party to the real-time network communication set exhibits the device property.

[0015] The above summary is not intended to describe each example embodiment or every implementation of the present disclosure.

[0016] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Brief explanation of the drawings]

[0017] [Figure 1] 1 illustrates a method for creating and applying rule sets for identifying properties of devices involved in network communications according to an embodiment of the present disclosure. [Figure 2] 1 illustrates a diagrammatic abstraction of a system for developing and applying rule sets for identifying properties of devices that are parties to network communications, according to an embodiment of the present disclosure. [Figure 3] 1 illustrates a method for extracting rules for inferring properties of a device from a machine learning model trained to infer the properties, according to an embodiment of the present disclosure. [Figure 4]1 illustrates exemplary major components of a computer system that may be used in accordance with an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0018] While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It is to 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.

[0019] FIELD OF THE DISCLOSURE Embodiments of the present disclosure relate to network security, and in particular to identifying properties of devices in network communications. While the present disclosure is not necessarily limited to such applications, various embodiments of the present disclosure may be understood through the discussion of various examples using this context.

[0020] Unauthorized access to certain communications networks (e.g., wired local area networks, wireless local area networks, and virtual local area networks) can be achieved by exploiting security vulnerabilities in devices authorized to the communications network. When vulnerabilities in certain devices (e.g., cell phone models and security camera models) or device types (e.g., IoT devices, devices made by certain manufacturers, devices with certain processor brands, and devices running certain software) are discovered or suspected publicly or among hacker groups, malicious actors (e.g., cybercriminals) may plan intrusion attempts targeting those devices or device types. If malicious actors can communicate with vulnerable devices on a network, they may exploit the vulnerability to gain unrestricted access to the vulnerable device. At that point, the cybercriminal may gain control of the device and use it to access other parts of the network undetected. In other words, cybercriminals may use the vulnerable device as a route to unauthorized access to the entire network.

[0021] For this reason, it may be beneficial for individuals maintaining communications networks (also referred to herein as "network administrators," which may include, for example, residential network owners and employees / contractors maintaining corporate networks) to monitor and filter incoming and outgoing network traffic to and from suspected vulnerable network devices. In theory, this could be done by filtering network communications based on the properties of the network devices involved in those communications. This could include, for example, filtering communications from a local area network (also referred to herein as a "LAN") to the Internet, filtering communications from the Internet to a LAN, filtering communications between virtual LANs (also referred to herein as vLANs) on a LAN, or filtering communications between devices on a single network (e.g., a single vLAN).

[0022] For example, a network administrator may conclude that Internet of Things devices (e.g., smart refrigerators, video doorbells) often have outdated and insecure firmware and therefore wish to limit the ability of IoT devices to contact (or be contacted by) the Internet. Similarly, some network devices only need to contact the Internet or other devices on the network for very specific purposes (e.g., time server synchronization), and therefore a network administrator may wish to limit those devices' ability to communicate with the time server's Internet address. Some specific devices (e.g., a particular smartphone model) may be known to be vulnerable to certain types of attacks (e.g., brute-force login attempts), and therefore a network administrator may wish to block Internet addresses that repeatedly attempt to log into one of these specific devices. Furthermore, some devices only need to communicate across the network for very limited purposes and therefore a network administrator may wish to restrict those devices from communicating with other network devices outside of those purposes (e.g., a network administrator may wish to prevent security cameras from communicating with storage servers on the network unless the storage server is configured to store footage from that security camera).

[0023] However, the properties of the network devices involved in the communication must be known in order for a network administrator to appropriately filter network communications based on those device properties. In very small networks, typically with a fixed set of network devices (e.g., home networks and small business networks that do not allow non-corporate-owned devices on the network), a skilled network administrator might be able to monitor device properties and filter Internet traffic based on those monitored devices.

[0024] However, many networks do not fall into these categories. For example, network administrators for many residential networks are typically home users who do not know or know how to identify all of the devices on their residential networks, let alone their properties or potential vulnerabilities. Similarly, many enterprise-level networks have a very large number of connected devices, the number of connected devices changes significantly over time, or both. Therefore, for many networks, maintaining an up-to-date knowledge base of the devices on the network, their properties, and their potential vulnerabilities may be beyond the capabilities of the network administrator, or even impossible.

[0025] For this reason, there is a theoretical advantage to automatically inferring the properties of network devices involved in network communications in real time. This is theoretically possible, for example, by analyzing network communications received by or intended to be sent to those network devices. For example, if a network controller device (e.g., a router device, a firewall device) detects a communication sent by a network device to an external IP address (e.g., a request to download an instruction set such as an executable file), the network controller device (sometimes referred to herein as a “network controller,” “controller,” or “controller device”) could analyze the device's traffic and determine that it is an IoT device (e.g., 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 could determine that a malicious actor is attempting to install intrusive software on the IoT device and block the communication. By inferring the properties of IoT devices in real time, the network controller could prevent malicious actors from installing software on the device, even if the properties of the IoT device are not known in advance.

[0026] However, inferring properties of network devices in real time by analyzing their communications is a computationally intensive activity. Typical general-purpose computing devices have historically struggled to do this, often taking a long time to do so. However, machine learning models (e.g., neural network classifiers, feedforward networks, recurrent neural networks, long short-term memory networks, and attention-based models) can be trained to accurately infer device properties based on those devices' traffic. In some cases, these machine learning models (sometimes referred to herein as "ML models") can be configured to infer device properties in near real time. These machine learning models can be trained, for example, to analyze past network communications labeled based on device type and associate patterns of those network communications with device type labels.

[0027] For example, machine learning models can be fed with past network communications for a network that includes multiple different device types. The machine learning models can be configured to analyze each communication individually or in conjunction with other communications and attempt to infer properties of the devices that are the source or destination of the communication. These machine learning models can be configured to infer device properties based on, for example, the destination, source, format, or content of the communication.

[0028] 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 infer device properties based on patterns in the DNS names (also referred to herein as “DNS addresses”) in those DNS queries. In this way, each communication to a particular DNS name(s) or a series of communications to a particular DNS name(s) may be considered an input to the machine learning model. Some machine learning models may similarly be configured to analyze actual traffic content (e.g., the network bytes of the communications) and infer device properties based on patterns observed in the content of the communications. For example, a smart remote from a particular manufacturer may have a particular signature in requests for firmware updates. The actual bytes of these communications may provide input to the machine learning model. Thus, the machine learning model may be trained to identify patterns in these inputs and infer device properties based on those conditions.

[0029] The device properties that a machine learning model is configured to infer may vary based on the use case for which the machine learning model is trained (e.g., network capabilities, network administrator security concerns, number of devices on the network, typical network activity). Some examples of device properties that a machine learning model may be configured to infer include the device's operating system, the presence of specific software on the device, the device classification (e.g., mobile phone, storage server, IoT device), the device manufacturer, the software version (or age of the software version) on the device, and the age of the device. These device properties may be specified in labels (e.g., metadata) attached to past network communications in the training data. During training of the machine learning model, the inferred device properties of devices involved in past communications may be compared to the actual device properties in such labels. The configuration of the machine learning model (e.g., weights and biases of neural network neurons) may then be adjusted based on whether the inferred properties match the actual device properties.

[0030] Once a machine learning model is sufficiently trained to infer device properties based on traffic (e.g., by communication events, communication content, and communication format), the machine learning model can typically infer properties of network devices involved in the traffic with sufficient accuracy to address network security concerns. Furthermore, if the accuracy of the machine learning model is insufficient, the machine learning model can typically be retrained with additional historical data (or real-time data) to remedy the inadequacies. For example, if the ML model can accurately infer that a communication was sent to a device manufactured by a particular company, but cannot accurately infer that the communication was sent by an IoT device, the ML model can be further trained with communications sent to and from IoT devices on the network.

[0031] While a typical, well-trained machine learning model is sufficiently accurate to infer device properties based on communications sent to and from that device, it is computationally intensive. This computational intensiveness increases the time it takes for the ML model to infer device properties. While this computational time may be acceptable for some use cases, applying such an ML model to real-time network communications can introduce significant, and in some cases unacceptable, network latency. In use cases where network speed is particularly important, the loss of this network latency may outweigh the benefit in the accuracy with which the ML model can infer device properties.

[0032] Thus, while ML models can theoretically help infer device properties for the purpose of filtering network traffic, in practice they are not fast enough to provide a standalone solution.For the above reasons, many use cases would benefit from a system that can infer properties of network devices based on their communications with the accuracy of ML models, but without the latency introduced by those models.

[0033] Some embodiments of the present disclosure address some of the problems identified above by extracting rules for inferring device properties from machine learning models that have been trained to infer device properties based on those device communications. In some embodiments, those rules are then analyzed for accuracy and, if sufficiently accurate, are applied to real-time network communications. The rules can then be used to analyze the real-time network communications in a computationally lightweight manner. This analysis can enable fast inference of properties of the devices involved in those communications, allowing for filtering of communications based on device properties without introducing significant network latency.

[0034] 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 set of network communications and infer properties of network devices involved in the communications (e.g., the transmitter of the communications or the intended recipient of the communications). In some embodiments of the present disclosure, the machine learning model may then analyze past network communications to train the model. These past communications may be annotated with device property labels that provide information about the properties of the network device(s) involved in the communications. For example, an attention-based machine learning model may be fed labeled past communications sent and received by the network on which the attention-based model is trained. The machine learning model may be trained by strengthening the model when the property inferences are correct and adjusting / retraining the model when the properties inferred by the model do not match the labels.

[0035] In some embodiments of the present disclosure, a machine learning model is trained until it is able to infer device properties with sufficient accuracy to address network security concerns. After the 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 significant inputs (e.g., a particular domain name, a particular communication format, a particular pattern of message bytes) that specifically influenced the ML model's inference of device properties.

[0036] In some embodiments, a wrapper, such as the LIME wrapper, may be applied to a classifier-type machine learning model when analyzing communications. Such a wrapper may cause the classifier to repeatedly analyze the same set of inputs, but fine-tune the inputs with each iteration. By detecting which adjustments affect the classifier's inference and which do not, the wrapper can identify inputs to the classifier that are likely to be most meaningful in the inferences made by the classifier about those communications. For example, if the classifier infers that a communication likely originated from a device made by a particular manufacturer, the wrapper may conclude that the DNS name of the manufacturer's firmware update server was the most meaningful input in that inference.

[0037] In some embodiments, an attention-based model may be used to infer network device properties rather than a classifier-type ML model (e.g., an RNN classifier). This may be beneficial because, unlike an RNN ML model, the importance of each part of the input to the attention-based model's conclusions may be examined based on the structure of the trained attention-based model. In particular, the model's attention weights may be used to determine, for a given device property, how important each section of network communication is when inferring that device property. Therefore, an attention-based model should not require a wrapper when identifying significant inputs for inferring a particular device property. Furthermore, in some embodiments, an algorithm may be used to directly analyze the attention weights to quickly extract significant inputs.

[0038] In some embodiments of the present disclosure, rules by which device properties may be inferred with or without an ML model may be formulated based on extracted inputs that are particularly significant to the inference of that device property by the ML model. These rules may take the form of formulaic conditional statements that can be easily parsed by a computer system (e.g., a finite state machine). These conditional statements may specify a device property to infer if a condition (e.g., the content of a network communication) is found. For example, in some embodiments, if-then statements may be formulated based on the extracted significant inputs. In some such embodiments, one or more of the significant inputs may be input into the condition (i.e., the "if" portion) of the if-then statement, and a corresponding device property may be input into the conclusion (i.e., the "then" portion) of the if-then statement. For example, if queries to the DNS name “ntp.iotproducer.com” are deemed particularly important in classifying a device as an IoT device made by manufacturer IoTProducer, a corresponding rule may be defined as follows: IF DNSname EQUALS ”ntp.iotproducer.com”, THEN device=IoT AND devicemanufacturer=IoTProducer.

[0039] In some embodiments, these rules may be created manually. For example, a network administrator may validate meaningful inputs for the ML model's inference of device properties and create if-then rules for the device properties. In some cases, this may be beneficial because the network administrator can take into account device contextual information or recognize the need for complex multi-condition rules. For example, rather than creating a rule that infers that a device is an IoT device if it queries a specific time synchronization server, a rule may infer that a device is an IoT device if it queries a specific time synchronization server at least 24 times per day, or if at least 90% of the device's DNS queries are to that specific time synchronization server.

[0040] However, in some use cases, the number of device properties for which inference rules are developed may make manual rule creation undesirable or impractical. Therefore, in some embodiments, these rules may be created automatically. For example, an algorithm (e.g., a sliding window algorithm) may consider model inputs above a certain weight (e.g., the 95th percentile) and generate all if-then sequences whose conditional parts ("if" parts) consist of inputs above that weight. These conditions may then be associated with device properties inferred by the ML model. In other words, the inferred properties may be input into the "then" parts of the if-then statements to create a series of if-then statements containing various combinations of conditions (e.g., queries to both domain X and domain Y, or queries to domain A or domain B) and inferred properties (e.g., smartphones from a particular manufacturer).

[0041] The configuration of such an algorithm may depend on the nature of the machine learning model used to identify significant inputs. For example, if a recurrent neural network is trained to infer device properties, the algorithm may be configured to analyze the wrapper's output to identify significant inputs that influenced the neural network's conclusions. Alternatively, if an attention-based model is trained to infer device properties, the algorithm may be configured to directly analyze the model's attention weights. Inputs with high attention weights (e.g., top five inputs, inputs with weights above a threshold, or inputs with weights above a certain percentile) may be identified as significant inputs. Either algorithm may then create a set of suggested inference rules based on the identified significant inputs.

[0042] In some embodiments, the created inference rules may be tested to assess their accuracy. This may be beneficial to ensure that the created rules can accurately infer desired device properties before relying on the rules in real-time communications. For example, in some embodiments, the rules may be tested on a second set of labeled historical data. The accuracy of the rules may then be determined (e.g., by calculating the F1 score of the rules).

[0043] However, in some cases, additional historical data may not be available to test the accuracy of inference rules. Thus, in some embodiments, rules may be tested on real-time communications. In these embodiments, to avoid relying on untested, potentially inaccurate inference rules, it may be beneficial to simultaneously rely on inferring or identifying device properties or other methods of filtering network communications (e.g., manually, using machine learning models, using traditional firewall rules). In some embodiments, the machine learning model that created the rules may also analyze real-time communications, allowing for a comparison of the accuracy of the machine learning model and the rules with respect to those communications.

[0044] If the rules are determined to be sufficiently accurate, they may be applied by the network controller device to real-time communications without requiring significant computational resources. For example, the 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. The controller device's conclusions using the rules (i.e., inferred properties of the network devices that are parties to the analyzed communications) may then be used by the network controller device when making traffic filtering decisions (e.g., blocking traffic from the Internet, blocking traffic between vLANs, etc.).

[0045] On the other hand, if the inference rules are determined to be insufficiently accurate, they can be verified by a network administrator. For example, the network administrator can compare the accuracy of the rules with the output of the ML model to ensure that the rules reflect the output of the ML model. If the inferences made by the ML model and the network controller device using the rules do not match, the rules may not capture the decision-making logic (e.g., attention weights) of the ML model. However, if the inferences made by the ML model and the rules match, the ML model may not have been trained sufficiently. Therefore, depending on the results of the verification, 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, increase the complexity of the rules based on the context of the network communication, etc.), or both.

[0046] 1 illustrates a method 100 for creating and applying rule sets for inferring properties of devices involved in network communications according to an embodiment of the present disclosure. Method 100 may be performed by a computer system, such as computer system 401, that has access to a set 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 the computer system that also executes the machine learning model (or instructs another computer on the network to execute the machine learning model).

[0047] Method 100 is presented as creating and applying a rule to infer a single device property 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 particular OS, the device is running firmware that has not been updated for two years). However, a similar method may be applied to creating and applying rules to infer multiple device properties. Similarly, multiple steps of method 100 may be performed to create one or more rules for each device property that a network administrator wants to be able to infer. For example, if a network administrator wants to be able to infer that a party to a network communication is a mobile phone, that a party to the communication is an IoT device, and that a party to the communication is manufactured by Insecure Devices Incorporated, method 100 may be performed three times (once for each property).

[0048] Method 100 begins at block 102, where a device property is selected. The device property selected at block 102 may be a property 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 known to be insecure and filter those network communications accordingly. Similarly, a network administrator may wish to determine whether devices involved in network communications are made by a manufacturer known for including insecure firmware in their devices or for failing to update firmware after the devices are manufactured. If method 100 is performed in a network where almost all network clients, except for employees' personal mobile phones, are company-owned, the network administrator may wish to determine whether the device is a mobile phone. Some network administrators may also wish to determine whether the device is an IoT device because they believe IoT devices are generally insecure.

[0049] Once the device property is selected in block 102, a machine learning model may be trained in block 104 to infer the device property based on the network communication. The machine learning model may be pre-configured to accept the network communication as input and output an inference of whether the network device involved in the communication exhibits the property selected in block 102. The machine learning model may be an attention-based model, a recurrent neural network, a feedforward neural network, etc., as previously described.

[0050] Block 104 may include, for example, receiving a set of past communications, each with a label indicating whether the device involved in the communication exhibited a selected property. For example, if "is an IoT device" is selected as the device property in block 102, the past data may include a first network communication in which a personal computer transmits an email to the Internet and a second communication in which an IoT lightbulb sends a message to a lightbulb manufacturer's server. In this example, the first network communication may be labeled (e.g., "NO," "FALSE," or "NOT IoT") to indicate that none of the devices involved in the communication are IoT devices. Meanwhile, the second network communication may be labeled (e.g., "YES," "TRUE," or "IoT") to indicate that the devices involved in the communication are IoT devices. This set of past communications may be referred to herein as "training data."

[0051] In some embodiments, different aspects of past 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 inference rules based on the ML model. In some embodiments, for example, the domain name to which each message was sent may be included in the training data. Including domain names may be useful for training a machine learning model to infer device properties of a network device based on patterns of domain names with which the network device communicates. In some embodiments, the content of each communication (i.e., the data sent in the communication) may be included in the training data. Including the content of the communication may be useful for training a machine learning model to infer device properties of a network device based on patterns of the device's network (or internet) activity. In some embodiments, metadata about the format of the communication (e.g., 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 the format of the communication may be useful for training a machine learning model to infer device properties of a network device based on patterns in how that device's (or all devices on the network of the same manufacturer or operating system) network communications are formatted. In some embodiments, other aspects of network communications may also be included.

[0052] In some embodiments, block 104 may include intentionally selecting aspects of past messages to include in the training data based on circumstances (e.g., the goals of a network administrator). For example, fully including all available data potentially relevant to a set of network communications may result in a more accurate machine learning model. However, increasing the size and complexity of the training data may increase both the time required to train the ML model and the time required (and the difficulty of extracting) the inputs that were most important to the ML model's inference. Thus, including too much may be detrimental in use cases where speed and ease of training and rule creation are particularly important. As another example, including only aspects of past communications directly relevant to a desired rule type (e.g., inferring device properties based on patterns in domain names queried by that device) may train the ML model quickly and increase the likelihood that the ML model will be trained to make inferences based on the desired inputs. However, excluding data from machine learning training may reduce the accuracy of the final trained model. Similarly, excluding data from the model may reduce the likelihood that rules created from the trained ML model will include useful context.

[0053] Block 104 includes training a machine learning model using the selected training data. For example, a labeled network communication (or set of communications) can be input to the machine learning model, and the machine learning model can provide an output inferring whether a network device involved in the communication(s) exhibits a device property for which the ML model is configured to make an inference. Early in the training process, the ML model may frequently make incorrect inferences, causing the model to be retrained (e.g., including adjusting bias or attention weights). The same or new network communications can then be input to the ML model again.

[0054] As the ML model is trained in block 104 (or after the ML model is deemed sufficiently trained), the controller device may determine, in block 106, whether the model is sufficiently accurate for the purposes of the network. In some embodiments, for example, a computer system overseeing method 100 may monitor the developing accuracy of the ML model as it is trained in block 104 and constantly compare that accuracy to a desired accuracy threshold. This may be beneficial because it allows the computer system to stop the training process in block 104 as soon as the ML model is sufficiently trained, avoiding unnecessary time and resources being spent overtraining the model on the training data. In some embodiments, the training process in block 104 may be stopped periodically to allow the accuracy of the ML model to be examined in block 106. This may include, for example, testing the ML model on previous training data or new training data. Testing the ML model on new training data may be beneficial because it may prevent the ML model from being overtrained on previous training data without being adaptable enough to make accurate inferences on other training data (or real-time data).

[0055] The exact metric used to evaluate the accuracy of an ML model can be chosen based on the situation and the network administrator's preferences. Some examples include raw accuracy (e.g., the total number of correct inferences divided by all inferences), model precision (e.g., correct positive inferences divided by the total number of positive inferences, correct negative inferences divided by the total number of negative inferences), recall (e.g., true positive inferences divided by the total number of true positive inferences and false negative inferences), and F1 score (a combination of precision and recall).

[0056] If the accuracy of the machine learning model is determined to be insufficient at block 106, 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 involve simply not interrupting the training process but allowing the ML model to continue training. 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 adaptability of the ML model.

[0057] However, if block 106 determines that the machine model is sufficiently accurate, the computer system overseeing method 100 may proceed to block 108, where significant inputs to the ML model's inference are extracted. As previously discussed, the specific 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 developed from the significant inputs.

[0058] 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 a LIME wrapper, to the ML model to monitor the effect of various adjustments to the inputs to the ML model on the ML model's inference. On the other hand, if the machine learning model trained in block 104 is an attention-based model, block 108 may simply include querying the attention weights applied to each input of the ML model.

[0059] Furthermore, if the training data used to train the ML model in block 104 is complex, the significant inputs extracted in block 108 may take a variety of forms. For example, if the ML model is trained on all available data related to a set of network communications, the extracted inputs may include any of that data (e.g., recipients of the communications, the time of the communications, how often the communications are sent, the format of the communications, etc.). On the other hand, if the ML model is trained only on DNS names queried by networking devices, the extracted inputs may only include the DNS name(s) that influenced inferring whether the device exhibited a device property.

[0060] In some cases, a significant input may be an input that, when seen by an ML model, causes the ML model to infer a particular device property based on that input alone. For example, a significant input may take the form of a domain name that, when queried by a network device, causes the ML model to infer that the device is an IoT device. However, in other cases, a significant input may be an input that causes the ML model to infer a particular device property only when seen together with other inputs. For example, in some cases, a significant input may be a series of bytes in the header of a network communication. When seen alone, that series of bytes may not be sufficient to make an inference of a device property. However, when the ML model sees that series of bytes and also sees 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 infer the device property of that network device.

[0061] Additionally, the implementation preferences of the network administrator may also affect the significant inputs extracted in block 108. For example, in some use cases, the network administrator may want only the most significant inputs to be extracted for rule creation, while in some use cases, the network administrator may want the five most significant inputs to be extracted.

[0062] The device properties being inferred may also influence the inputs that are deemed important: inputs that may be particularly useful for inferring that a device is an IoT device may be quite different from inputs that may be useful for inferring that the device is a device from a particular manufacturer or that the device is a personal mobile phone.

[0063] In some embodiments, extracting significant inputs may also include extracting weights that numerically represent the significance that the inputs had to the inference of the ML model. For example, if the ML model trained in block 104 is an attention-based model, each extracted significant input may also be accompanied by the attention weight for that input.

[0064] Thus, if a machine learning model is trained in block 104 to analyze a set of DNS names queried by a network device, the significant input extracted in block 108 may take the form of a list of (1) the 10 DNS names that had the most influence on the ML model's inference due to their presence in the input data, and (2) for each of the 10 DNS names, a numerical weight given to that DNS name.

[0065] Once the significant inputs are extracted in block 108, a set of inference rules is created in block 110 based on the extracted inputs. As previously mentioned, these inference rules may take the form of if-then statements that include a condition and a conclusion (here, an inference) based on the condition. For example, a rule may be created in the form of the following statement: condition "if 'DNS name' = 'ntp.manufacturer.com' and 'device-metrics-us.manufacturer.com'" and conclusion "then 'device manufacturer' = 'manufacturer'". This rule, when analyzed by a computer (e.g., a general-purpose computer system or a finite state machine), would conclude that when a network device queries both "ntp.manufacturer.com" and "device-metrics-us.manufacturer.com", the device was manufactured by "manufacturer".

[0066] In some embodiments, the inference rules created in block 110 may be created manually (e.g., by a network administrator) or automatically. In use cases where the important input extracted is a simple, short set, automatically creating the rules may result in a manageable rule set. For example, if the top three DNS names are extracted in block 108, block 110 may include automatically incorporating each of those DNS names into a rule that concludes that the device property is indicated if that single DNS name is present. Block 110 may also incorporate each possible pair of DNS names combined with an “AND” operator (resulting in a condition requiring both names), an “OR” operator (resulting in a condition requiring either or both DNS names), and an “XOR” operator (resulting in a condition requiring one DNS name but not satisfied if both DNS names are present). In some embodiments, all three DNS names may be combined into a condition, such as a condition requiring the first two DNS names but not the third DNS name. The resulting set, or inference rules, may include 25 or fewer rules, making selecting the correct inference rule(s) manageable.

[0067] In some embodiments, the extracted inputs may enable more complex inference rules to be created. For example, if the significant inputs extracted in block 108 include timestamps of network communications, the rules created in block 110 may utilize those timestamps. For example, rules may be created that include a condition that a network device sends communications to an IP address during a specific time period (e.g., between 2:00 AM and 4:00 AM) or with a certain frequency (e.g., at least 40 times per day). In embodiments in which most or all of the data related to network communications is included in the training data, the extracted inputs may enable even more complex rules. For example, a sequence mining algorithm (such as a PrefixSpan algorithm) may collect sequences of events in the significant inputs extracted in 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.

[0068] In some use cases, a network administrator may prefer to prevent the initial set of rules created in block 110 from being overly complex. This could potentially avoid unnecessary rule testing and analysis in later blocks of method 100. For this reason, block 110 may initially create simple rules (e.g., simple if-then statements) by default. In some embodiments, it may also be preferred that rules be created or verified by the network administrator. The network administrator may be able to identify contexts in the inputs where the rule creation algorithm cannot identify. For this reason, the network administrator may be able to eliminate rules that the network administrator has reason to believe are inaccurate even when created using significant inputs (e.g., rules that require a device to query both the manufacturer's NTP server and a competitor's NTP server).

[0069] After the set of inference rules is created in block 110, the rules may be tested for accuracy in block 112. In some embodiments, testing the inference rules may include applying the inference rules to a new set of data using a computer system (e.g., a general-purpose computer processor). For example, the computer may load the inference rules into memory, receive a new network communication, and compare the network communication to the "condition" text of the inference rule. If the data in the network communication matches the condition, the computer infers that the device involved in the communication exhibits the device property. For example, if the condition is "DNS name=ntp.smarttoaster.com" and the network communication is a query to ntp.smarttoaster.com, the computer concludes that the device involved in the communication (here, the sending device) exhibits the device property (e.g., that the device is a smart toaster).

[0070] Using a new data set rather than previous training data at block 112 may beneficially reduce the likelihood that a rule will be well suited to previous training data but poorly suited to making inferences based on data that differs from the previous training data. In other words, method 100 may avoid "overtraining" the data on previous training data by testing the created inference rules with new data. In some embodiments, a mixture of new and old training data (e.g., 80% old training data, 20% new data) may be used to test the rules.

[0071] 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 within the network. If a second set of historical training data is used, the conclusions of a computer applying the created rules to the second training data set may be compared to the labels in the training data or to the inferences of an ML model trained on the second training data set. However, if real-time data is used for the new data set, it may be particularly beneficial to also analyze the new data set with the machine learning model trained in block 104, since real-time data is less likely to be labeled. The inferences of the computer running the inference rules and the machine learning model may then be compared for accuracy.

[0072] In some embodiments, determining whether the generated inference rules at block 112 are sufficiently accurate may include performing accuracy calculations similar to those performed for the trained ML model at block 106. For example, raw accuracy, precision, recall, F1-score, or a combination thereof may be calculated for each generated rule. These measures may then be compared to one or more accuracy thresholds (e.g., a precision threshold, an F1-score threshold) at block 112.

[0073] If block 112 determines that the rule is not sufficiently accurate, then block 114 validates the rule. In some embodiments, block 114 may include a step in which a human verifier (e.g., a network administrator) analyzes the rule for sources of error. For example, human validation may validate the rule for potential parsing errors. The human verifier may also examine context within the training data that may explain or be useful in avoiding inaccuracies. The human verifier may also validate key inputs extracted in block 108 for potential errors (e.g., inputs based on the content of network communications that are highly likely to be found in nearly all communications on the network).

[0074] In some cases, validating the rule at 114 may indicate that the rule could be improved. For example, if the rule created at block 110 takes the form of an if-then statement that infers a device property if a communication is sent to a particular DNS name, and block 112 determines that the rule results in an unacceptable number of false positive references, validating the rule at block 114 may reveal that adding context from training data suggests modifying the rule to infer a device property when a communication is sent to that particular DNS name at least six times in a 24-hour period. Rule modification can be accomplished by increasing the complexity of the rule creation algorithm (e.g., from a simple algorithm that plugs a single domain into an if-then rule) to a more complex algorithm that considers the timing of communications, the impact of other network communications, the sequence between communications, or all of the above (e.g., a PrefixSpan algorithm). Rule modification at block 114 can also be performed by a human validator, such as a network administrator.

[0075] In some cases, a rule may be determined to be inaccurate at block 112 because the machine learning model on which the rule is based (or the important inputs on which the rule is based) is not accurate with the new data used at block 112. In these cases, method 100 may include returning from block 114 to block 104, at which point the machine learning model may be further retrained. However, in most cases, performing 104 on a sufficiently large training set and setting the accuracy threshold at block 106 appropriately high should prevent inaccuracies at block 112 due to undertraining the network. For this reason, block 114 would normally proceed to block 112 and is illustrated as such here.

[0076] After validating and modifying the rule, block 112 again determines whether the rule is sufficiently accurate. This subsequent iteration of block 112 may include the same analysis as described above. If block 112 determines that the rule is sufficiently accurate, then the rule may be applied at block 116. In some embodiments, block 116 may include adding the created rule to an "approved" rule list for potential later application to real-time network traffic. In some embodiments, block 116 may include applying the rule to real-time live data. As discussed above, this may be performed by a general-purpose computer with a processor configured to compare live network communications with the conditions of the created rule (e.g., using a string comparison). For most created rules, a simple finite state machine may be sufficient for this comparison. When these rules are applied to real-time network communications, inferences made based on these rules may be used when making manual or automatic traffic filtering decisions (e.g., determining whether to block traffic to IoT devices or prevent devices with vulnerable operating systems from contacting VLANs hosting network controller devices or VLANs with sensitive storage). In some embodiments, this rule application may occur, for example, on a network firewall device or a router device.

[0077] For ease of understanding, Figure 2 illustrates a schematic abstraction 200 of a system for developing and applying rule sets for inferring properties of devices 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 disclosed process. Thus, the components and suggested process of schematic abstraction 200 are a simplified abstraction and are not intended to be an exact representation of an embodiment of the present disclosure.

[0078] In the graphical representation 200, a set of network communications 202 is input to a machine learning model 204 to train the model to infer device properties of devices involved in those network communications. In some embodiments, the device properties are preselected, and the content of the network communications 202 is selected for training purposes. Thus, the network communications 202 may include labels that indicate whether the parties to the communication exhibited the device properties. The content of the network communications 202 may be selected to target the rationale for the inferences made by the machine learning model 204. For example, if a network administrator wants to train the machine learning model 204 to make inferences based on the actual bytes of the network communications rather than, for example, information about the sender or intended recipient, the network communications 202 may be reduced to include only the message content, rather than additional communication data.

[0079] Once the machine learning model 204 has been properly trained to infer device properties based on the network communications 202, the machine learning model 204 itself is analyzed by the computer system 206. The computer system 206 may be any computer capable of analyzing the machine learning model 204 to extract meaningful inputs in the inferences made by the machine learning model 204. For example, if the machine learning model 204 is a recurrent neural network, the computer system 206 may be a system with a processor capable of executing a LIME wrapper. If the machine learning model 204 is an attention-based network, the computer system 206 may be a system with a processor capable of identifying and ranking attention weights for the machine learning model 204. In some embodiments, the computer system 206 may be a computer system hosted on a network responsible for managing network communications (e.g., a network controller device or a computer running network controller software).

[0080] The computer system 206 may then create inference rules 208 based on the extracted significant inputs. In some embodiments, the computer system 206 may utilize a single algorithm that can, for example, both extract inputs and formulate the inference rules 208 (shown here as a list of five conditions on the left side and a list of five corresponding inferences on the right side). This may be beneficial when extracting significant inputs from attention-based models because the attention weights may be easily accessible to an algorithm specialized for rule creation. In some embodiments, the rule creation algorithm may obtain the extracted significant inputs from a separate wrapper applied to the neural network 204.

[0081] Once inference rules 208 are created, they are applied to new network communication set 210 by computer system 212. In some embodiments, new network communication set 210 may be a set of additional training data for validating inference rules 208. In other embodiments, new network communication set 210 may be live, real-time network traffic. Computer system 212 may, in some embodiments, be the same computer system (e.g., a network controller device) as computer system 206 or a different computer system. In some embodiments, computer system 212 may be any computer system capable of performing a string comparison between the conditions of inference rules 208 and network communication set 210.

[0082] The computer system 212 may output an inference 214. As shown, the inference 214 indicates that the computer system 212 has found two conditions to be satisfied (i.e., the first condition and the fourth condition) and may therefore infer that the device involved in the network communication 210 exhibits corresponding first and fourth device properties. As presented, FIG. 2 illustrates an example in which two device properties are inferred. For example, the computer system 212 may infer that the device involved in the network communication 210 is an IoT device (e.g., the first condition) with firmware that is more than one year old (e.g., the fourth condition). However, in some embodiments of the present invention, only one device property may be inferred per rule set.

[0083] As mentioned above, the extraction of important inputs and the creation of rules based on those inputs may vary depending on the context (e.g., properties of the ML model, preferences of a network administrator). For this reason, and for purposes of understanding, FIG. 3 is presented as an example method 300 for extracting rules for inferring properties of a device from an ML model trained to infer the properties, according to an embodiment of the present disclosure. Method 300 may be performed by a computer system (e.g., a network controller device or a system hosting network controller software), such as computer system 401 configured to monitor and control network communications on a network.

[0084] Method 300 begins at block 302, where an attention-based machine learning model is trained to infer whether devices involved in one or more network communications exhibit preselected device properties based on those network communications. Details of block 302 are found throughout this disclosure. Specific examples are found with respect to block 104 of FIG. 1 and machine learning model 204 of FIG. 2. Once the attention-based model is trained at block 302, input extraction may begin at block 304.

[0085] At block 304, devices inferred by the attention-based model are identified. For example, each communication set analyzed by the attention-based model in the data set may be assigned a unique hypothetical network device. At block 304, for each communication set for which the attention-based model infers the presence of a preselected property, the hypothetical device may be added to an “identified” list of devices. For example, if the attention model analyzes 10 communication sets and infers that a preselected property (e.g., IoT device) is present in five of the sets, block 304 may result in identifying five unique devices that exhibit the preselected property (here, the property of being an IoT device). This may be true even if the actual network from which the 10 communication sets originated consists of only two devices, only one of which is an IoT device. For purposes of method 300, it may be sufficient to treat each communication set as corresponding to a unique device.

[0086] For each device (e.g., each hypothetical device) identified in block 304, block 306 identifies an attention weight assigned to each input (e.g., the communication's header, the communication's destination address). In other words, for each set of communications, block 306 determines the relevance that each aspect of the communications had to the inference that the corresponding device exhibited a preselected property. In an attention-based model, these attention weights take the form of a mathematical importance formula applied to each input and may be derived directly from the structure of the model. Thus, block 306 may take the form of extracting, for each device identified in block 304, its attention weight directly from the model, resulting in a list of attention weights for each identified device. In some embodiments, for example, this list may take the form of a list of DNS names to which communications in the set of communications were directed, along with a numerical value for each DNS name representing the influence that the presence of that DNS name had on the inference.

[0087] At block 308, the attention weights identified at block 306 are summed for each device. For example, if five devices were identified at block 304 and the attention weights for the attention-based model for the DNS name firmware_fetch.manufacturer.com were 0.2, 0.1, 0.1, 0.3, and 0.2 for those five devices, respectively, block 308 may include summing those attention weights to yield a combined weight of 0.9 for the DNS name firmware_fetch.manufacturer.com for the set of identified devices. This summation process may be repeated for each input for which an attention weight is available. For example, if the data on which the attention model was trained includes queries to 30 DNS names, block 308 may yield a list of 30 combined weights, each of which represents the aggregate attention weight given to that DNS name across all five identified devices.

[0088] Once the combination weights are created in block 308, the combination weights are ranked in block 310. This may include, for example, ordering the combination weights in descending order. In other words, the largest combination weight is listed first, and the smallest combination weight is listed last. Because each combination weight corresponds to the sum of the weights of one input across all devices identified in block 304, the result of block 310 provides a list of inputs that had the most influence on the attention-based model's inference across all identified devices.

[0089] Using the ranked list of combined attention weights, the computer system may generate inference rules based on the most influential inputs in block 312. For example, an algorithm may automatically retrieve the five most influential inputs and insert them into simple if-then statements where the "if" condition is the presence of the influential input and the "then" condition is an inference of a device property. As mentioned above, these generated rules may, in some embodiments, be more complex and incorporate more context (e.g., requiring the presence of two ranked inputs to generate an inference of a device property, requiring the presence of an input at least X times over Y time period, or requiring a specific sequence of inputs). Rules generated as part of method 300 may then be tested for accuracy by any method discussed herein. If accurate, the generated rules may be applied to real-time network communications.

[0090] FIG. 4 illustrates representative major components of an example computer system 401 that may be used in accordance with embodiments of the present disclosure. The specific components illustrated are presented for illustrative purposes only and are not necessarily all variations thereof. Computer system 401 may include a processor 410, memory 420, an input / output interface (also referred to herein as I / O or I / O interface) 430, and a 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).

[0091] The processor 410 of the computer system 401 may include one or more CPUs 412. The processor 410 may further include one or more memory buffers or caches (not shown) that provide temporary storage of instructions and data for the CPU 412. The CPU 412 may execute instructions based on input provided from the cache or from the memory 420 and output results to the cache or memory 420. The 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, the computer system 401 may include multiple processors 410, as is typical of relatively large systems. However, in other embodiments, the computer system 401 may be a single processor with only one CPU 412.

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

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

[0094] Logic modules throughout computer system 401, including but not limited to memory 420, processor 410, and I / O interface 430, may communicate failures and changes in one or more components to a hypervisor or operating system (not shown). The hypervisor or operating system may allocate the various resources available in computer system 401 and track the location of data in memory 420 and processes assigned to the various CPUs 412. In embodiments that combine or rearrange elements, aspects of the capabilities of the logic modules may be combined or redistributed. These variations will be apparent to those skilled in the art.

[0095] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include computer-readable storage medium(s) having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0096] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of further specific examples of computer-readable storage media includes portable computer diskettes, hard disks, 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 disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as transitory signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through wires.

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

[0098] Computer-readable program instructions for carrying out operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++, 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, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0099] 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.

[0100] 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 the instructions, which execute on the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0101] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational acts on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions, executing on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0102] The flowcharts 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 flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). 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 accomplished as a single step, or may be executed simultaneously, substantially simultaneously, partially, or fully overlapping in time, depending on the functionality involved, or the blocks may even be executed in the reverse order. It should also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0103] The description of various embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Numerous 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 have been selected to explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the market, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. analyzing a first network communication according to a first input set with a machine learning model; inferring, by the machine learning model, based on the analysis, that a first device that is a party to the first network communication exhibits a device property; extracting from the machine learning model a first set of significant inputs that significantly influenced the inference; using the first set of significant inputs to create rules for identifying the device properties, the rules including conditions that, when present in a network communication, suggest that a party to the network communication exhibits the device properties; A method comprising:

2. The extracting step includes: identifying an input weight for each input in the first input set; ranking the input weights for the first set of inputs; selecting the first set of significant inputs based on the ranking; The method of claim 1 , comprising:

3. analyzing a second network communication according to a second input set with the machine learning model; inferring, by the machine learning model, based on the analysis, that a second device that is a party to the second network communication exhibits the device property; further comprising The extracting step includes: identifying an input weight for each input of the second input set; combining the input weights of the first set of inputs and the second set of inputs; The method of claim 2 further comprising:

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. applying said rules to real-time network communications; detecting whether the real-time network communication data matches the condition; inferring, based on said detecting, that a second device that is a party to said real-time network communication exhibits said device property; blocking the real-time network communication based on an inference by the second device indicating the device property; The method of claim 1 further comprising:

7. The method of claim 1 , wherein the first set of significant inputs includes a domain name.

8. a processor; a memory in communication with the processor, the memory including program instructions configured, when executed by the processor, to cause the processor to perform a method, the method comprising: analyzing a first set of network communications according to a first set of inputs with a machine learning model; inferring, by the machine learning model, based on the analysis, that each device in a device set exhibits a device property, each device being a party to network communications in the first network communication set; extracting from the machine learning model a first set of significant inputs that significantly influenced the inference; creating rules for identifying the device property using the first set of significant inputs, the rules including conditions that, when present in a real-time network communication set, suggest that a party to the real-time network communication set exhibits the device property; Including memory and A system including:

9. The machine learning model is an attention-based model, and the extracting step includes: identifying, for a particular device in the set of devices, a list of attention weights representing the importance of each particular input in the first set of inputs for the inference about that particular device; for a particular input of the particular device, combining the attention weight in the list with the attention weights of corresponding inputs in the input sets of other devices in the device set to result in a combined weight for that input for all devices in the device set; comparing the combined weights to other combined weights of other inputs in the input set; determining, based on the comparison, that the particular input is a significant input; adding the particular input to the first set of significant inputs; The system of claim 8 , comprising:

10. 10. The system of claim 9, wherein the particular entry for the particular device is a DNS name that the particular device has queried, and the corresponding entries for the other devices in the device set are the DNS names that those other devices have queried.

11. 11. The system of claim 10, wherein the rule comprises inferring that a network device exhibits the device property if the network device queries the DNS name.

12. 11. The system of claim 10, wherein the rule comprises inferring that the network device exhibits the device property if the network device queries the DNS name and a second DNS name.

13. The system of claim 8 , wherein the first set of significant inputs comprises a particular sequence of bytes in a real-time network communication.

14. 9. The system of claim 8, wherein the first set of significant inputs includes a DNS name, and the condition includes querying the DNS name at least a threshold number of times over a particular period of time.

15. A computer program comprising: analyzing a first set of network communications according to a first set of inputs with a machine learning model; causing the machine learning model to infer, based on the analysis, that each device in a device set exhibits a device property, where each device is a party to network communications in the first network communication set; extracting from the machine learning model a first set of significant inputs that significantly influenced the inference; Using the first set of meaningful inputs, create rules for identifying the device property, wherein the rules include a condition that, when present in a real-time network communication set, suggests that a party to the real-time network communication set exhibits the device property. Computer program.

16. The machine learning model is an attention-based model, and the extracting step includes: identifying, for a particular device in the set of devices, a list of attention weights representing the importance of each particular input in the first set of inputs for the inference about that particular device; for a particular input of the particular device, combining the attention weight in the list with the attention weights of corresponding inputs in the input sets of other devices in the device set to result in a combined weight for that input for all devices in the device set; 16. The computer program of claim 15, comprising:

17. 17. The computer program product of claim 16, wherein the particular input for the particular device is a DNS name that the particular device has queried, and the corresponding inputs for the other devices in the device set are the DNS names that those other devices have queried.

18. 20. The computer program product of claim 17, wherein the rule comprises inferring that a network device will exhibit the device property if the network device queries the DNS name.

19. 18. The computer program product of claim 17, wherein the rule comprises inferring that a network device exhibits the device property if the network device queries the DNS name and a second DNS name.

20. 16. The computer program product of claim 15, wherein the first set of significant inputs includes a DNS name, and the condition includes querying the DNS name at least a threshold number of times over a particular period of time.

21. A computer program comprising program code means adapted to perform the method according to any one of claims 1 to 7 when the program is run on a computer.

Images