WO2023031804A1 - Combining device behavioral models and building schema for cyber-security of large-scale iot infrastructure - Google Patents
Combining device behavioral models and building schema for cyber-security of large-scale iot infrastructure Download PDFInfo
- Publication number
- WO2023031804A1 WO2023031804A1 PCT/IB2022/058136 IB2022058136W WO2023031804A1 WO 2023031804 A1 WO2023031804 A1 WO 2023031804A1 IB 2022058136 W IB2022058136 W IB 2022058136W WO 2023031804 A1 WO2023031804 A1 WO 2023031804A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- network
- behavior
- devices
- model
- physical environment
- Prior art date
Links
- 230000003542 behavioural effect Effects 0.000 title description 5
- 238000000034 method Methods 0.000 claims abstract description 152
- 230000006399 behavior Effects 0.000 claims description 122
- 238000004891 communication Methods 0.000 claims description 39
- 238000001514 detection method Methods 0.000 claims description 38
- 230000002547 anomalous effect Effects 0.000 claims description 35
- 239000011449 brick Substances 0.000 claims description 29
- 230000000694 effects Effects 0.000 claims description 24
- 238000010801 machine learning Methods 0.000 claims description 16
- 238000012795 verification Methods 0.000 claims description 12
- 239000011454 mudbrick Substances 0.000 claims description 11
- 230000006855 networking Effects 0.000 claims description 9
- 230000003993 interaction Effects 0.000 claims description 5
- 238000012423 maintenance Methods 0.000 claims description 5
- 238000012549 training Methods 0.000 claims description 5
- 239000004566 building material Substances 0.000 claims description 4
- 238000005065 mining Methods 0.000 claims description 3
- 238000013450 outlier detection Methods 0.000 claims description 3
- 239000004065 semiconductor Substances 0.000 claims description 3
- 239000000126 substance Substances 0.000 claims description 3
- 238000004378 air conditioning Methods 0.000 claims description 2
- 238000010438 heat treatment Methods 0.000 claims description 2
- 238000009423 ventilation Methods 0.000 claims description 2
- 230000008569 process Effects 0.000 description 9
- 230000005540 biological transmission Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 8
- 238000012544 monitoring process Methods 0.000 description 6
- 238000000899 pressurised-fluid extraction Methods 0.000 description 6
- 230000003068 static effect Effects 0.000 description 6
- 230000000670 limiting effect Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 238000000513 principal component analysis Methods 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000011156 evaluation Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000008520 organization Effects 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 3
- 238000013499 data model Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000002829 reductive effect Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 239000013589 supplement Substances 0.000 description 3
- 230000002123 temporal effect Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 102100026278 Cysteine sulfinic acid decarboxylase Human genes 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000027455 binding Effects 0.000 description 2
- 238000009739 binding Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000003745 diagnosis Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000036961 partial effect Effects 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 108010064775 protein C activator peptide Proteins 0.000 description 2
- 238000013138 pruning Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000009897 systematic effect Effects 0.000 description 2
- KJLPSBMDOIVXSN-UHFFFAOYSA-N 4-[4-[2-[4-(3,4-dicarboxyphenoxy)phenyl]propan-2-yl]phenoxy]phthalic acid Chemical compound C=1C=C(OC=2C=C(C(C(O)=O)=CC=2)C(O)=O)C=CC=1C(C)(C)C(C=C1)=CC=C1OC1=CC=C(C(O)=O)C(C(O)=O)=C1 KJLPSBMDOIVXSN-UHFFFAOYSA-N 0.000 description 1
- 241000613399 Borelis Species 0.000 description 1
- UGFAIRIUMAVXCW-UHFFFAOYSA-N Carbon monoxide Chemical compound [O+]#[C-] UGFAIRIUMAVXCW-UHFFFAOYSA-N 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 239000011469 building brick Substances 0.000 description 1
- 229910002091 carbon monoxide Inorganic materials 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 230000008260 defense mechanism Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000008570 general process Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 230000004224 protection Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012502 risk assessment Methods 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 238000012731 temporal analysis Methods 0.000 description 1
- 238000000700 time series analysis Methods 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
- G16Y30/00—IoT infrastructure
- G16Y30/10—Security thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
Definitions
- Embodiments of the present disclosure relate to network security, and more particularly, to using data models in network cybersecurity.
- a large loT infrastructure for smart buildings may consist of many subsystems such as Heating, ventilation, and air conditioning (HVAC), lighting, access controllers, occupancy sensors, or physical security systems.
- HVAC Heating, ventilation, and air conditioning
- These subsystems are often managed by a variety of stakeholders from network architect, network engineers, facility management engineers, and cybersecurity analysts to device manufactures, system integrators, and building managers throughout the life-cycle of a smart building. These stakeholders produce different data schema to maintain information about the physical location, network configuration, or security policies of loT devices.
- loT controllers based on data collected from many devices such as security cameras, smart-lights, smoke-alarms, or occupancy sensors sourced from a diversity of vendors. Integrating cloud-based servers with many different types of devices, each with their own security flaws (e.g., weak/no encryption, open ports, default username/passwords) exponentially increases the potential attack surfaces on smart environments.
- Embodiments of the present disclosure may include a method for enforcing network flow rules of a heterogeneous network of devices including receiving a description of a physical environment.
- Embodiments may also include receiving a device behavior profile of a plurality of network devices.
- Embodiments may also include receiving at least one network configuration input.
- Embodiments may also include translating the received description of the physical environment, the received device behavior profile, and the at least one network configuration input into a formal model.
- Embodiments may also include determining network flow rules based at least in part on the formal model.
- Embodiments may also include enforcing the network flow rules.
- the network flow rules enhance the security of a heterogeneous network of devices.
- a description of a physical environment may include a combination of at least one of a room name, a sensor, a utility, a building material, a building floor, a building performance, an asset list, a stairwell, an elevator, a structural element, a fire escape, a furniture piece, an available resource, a time restricted use, a temperature setting, a humidity setting, an air quality parameter, an area occupancy, an area dimension, an area usage restriction, a maintenance status, a password, a username, an area access restriction, a status, an occupancy restriction, a door, a window, an architectural floor plan, or an area intended use.
- the physical environment is at least one of a building, a campus, a maritime craft, a rail-based transportation system, an oil refinery, a mining operation, a chemical plant, a nuclear plant, an alternative energy plant, a nursery, an agricultural field, a municipality, a semiconductor foundry, a port, a warehouse, a stadium, or a university campus.
- a description of a physical environment may also include a class and a tag.
- the class and the tag are used to describe a relationship amongst two or more network devices amongst the plurality of network devices.
- a description of a physical environment is a hierarchical construct of a relationship of at least two network devices based at least in part on a class of each of the two network devices and one or more tags.
- a description of a physical environment may include a Resource Description Framework (RDF) syntax to maintain a system ontology.
- RDF Resource Description Framework
- Embodiments may also include an interaction with the system ontology using a query-based language.
- a query-based language is SPARQL Protocol and RDF Query Language (SPARQL).
- a description of a physical environment may include a Brick model.
- a description of a physical environment may include metadata.
- a device behavior profile may include a pattern of device communications.
- a pattern of device communications may include a set of machine-readable constructs describing a network flow of the network device.
- a device behavior profile is based at least in part on an Internet Engineering Task Eorce IETE Manufacturer Usage Description (MUD) Standard.
- a device behavior profile may include access control entries (ACE) of the network device.
- the access control entries (ACE) of the network device are serialized in a JavaScript Object Notation (JSON) format.
- the access control entries describe a direction of communication of the network device.
- a direction of communication of the network device may include an at least from device and an at least one to-device direction.
- Embodiments may also include access control entries (ACE) of the network device match based at least in part on one of a source port number or a destination port number for Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), and a type and code for Internet Control Message Protocol (ICMP).
- TCP Transmission Control Protocol
- UDP User Datagram Protocol
- ICMP Internet Control Message Protocol
- a pattern of device communications distinguishes local network traffic from Internet communications.
- a pattern of device communications provides a support of ambiguities through a controller tag.
- the receiving a device behavior profile of a plurality of network devices may also include discovering at least one network devices.
- a network device is one of a security camera, a thermostat, an occupancy sensor, an HVAC system, a lighting system, an access controller, a fire alarm, a physical security system, a camera, a networked appliance, an industrial device, or a robotic device.
- a device behavior profile may include a semantic, the semantic may include at least one class and at least one property.
- an at least one network configuration input is a network address, a port, or a Virtual Local Area Network (VLAN).
- receiving at least one network configuration input may include running an IP address retrieval query.
- running an IP address retrieval query may include running a SPARQL query.
- receiving at least one network configuration input may include receiving a network configuration file of the plurality of network devices.
- receiving at least one network configuration input may include receiving at least one file such as a spreadsheet or a text file.
- the spreadsheet or the text file of network configurations of the plurality of network devices may include receiving at least one file such as a spreadsheet or a text file.
- receiving at least one network configuration input may include receiving a semantic schema.
- the semantic schema may include at least one class and at least one property.
- the translating a formal model is translated via a modelling tool.
- the modelling tool is a MudBrick tool.
- the MudBrick tool may also include a linker module.
- the linker module translates the received description of the physical environment, the received device behavior profile, and the at least one network configuration input into the formal model.
- the linker module is extensible accepting various formats of an organizational network device configuration.
- the formal model may include a knowledge representation of a network ontology.
- the translating a formal model is translated via a linker module.
- the linker module builds a machine-readable knowledge representation of the formal model.
- translating the received description of the physical environment, the received device behavior profile, and the at least one network configuration input into a formal model may include, combining a semantic of the received description of the physical environment, and a semantic of the received device behavior profile into a machine- readable knowledge representation of the heterogeneous network of devices.
- translating the received description of the physical environment, the received device behavior profile, and the at least one network configuration input into a formal model may include, combining at least one class and at least one property of the received description of the physical environment with at least one class and at least one property of the received device behavior profile into a machine -readable knowledge representation of the heterogeneous network of devices.
- combining at least one class and at least one property of the received description of the physical environment with at least one class and at least one property of the received device behavior profile into a machine-readable knowledge representation of the heterogeneous network of devices may also include receiving a unique identifier for each of the description of the physical environment, the device behavior profile of each of the plurality of network devices, and the at least one network configuration input.
- Embodiments may also include correlating unique identifiers for each of the description of the physical environment, the device behavior profile of each of the plurality of network devices, and the at least one network configuration input to create a combined MUD Brick profile.
- the unique identifier for each of the description of the physical environment and the at least one network configuration input is at least one of a Media Access Control (MAC) address or an IP address and the unique identifier for each of the device behavior profile of each of the plurality of network devices and the description of the physical environment is a class.
- the determining network flow rules is based at least in part on the formal model.
- ACE access control entries
- the network flow rules may include rules priority to govern network activity of the plurality of network devices.
- the determining network flow rules may include an access control list (ACL).
- the network flow rules may include a deterministic routing policy based at least in part on the description of a physical environment for each network device of the plurality of network devices.
- the description of a physical environment for each network device is a physical location of the network device.
- determining network flow rules based at least in part on the formal model may include verifying the formal model is compliant with an organizational policy.
- the verifying the formal model is compliant with an organizational policy may also include identifying a network traffic flow that violates the organizational policy.
- the network traffic flow that violates the organizational policy is removed from the network flow rules. In some embodiments, the network traffic flow that violates the organizational policy is modified to comply with the organizational policy. Embodiments may also include the determining network flow rules is based at least in part on by applying a plurality of network policies to the formal model.
- enforcing the network flow rules may include using a programmable networking technique.
- the programmable networking technique is implemented using a programmable switch.
- the programmable networking technique is implemented using a Software Defined Network switch.
- the network flow rules may include at least one location-defined network policy.
- the at least one location-defined network policy is a deployment policy, an administrative policy, and an organizational policy. In some embodiments, the at least one location-defined network policy restricts access of a resource to at least one operational zone. Embodiments may also include verifying an intended system behavior of the network device. Embodiments may also include periodically collecting network run-time activity from a network switch.
- the periodically collecting network run-time activity from a network switch is performed by a dynamic verification application.
- the run-time activity is analyzed by a set of pre-trained anomaly detection models.
- the set of pre-trained anomaly detection models is trained to a particular network device and the description of the physical environment.
- Embodiments may also include determining anomalous behavior of at least one network device based on the network flow rules.
- the determining anomalous behavior may include employing at least one data-driven model based at least in part on at least one device behavior profile of a plurality of network devices.
- the determining anomalous behavior may include applying a machine learning technique to distinguish a normal device network behavior from an anomalous device network behavior.
- the applying a machine learning technique to distinguish a normal device network behavior from an anomalous device network behavior may include training a machine learning technique with a benign network traffic profile of an loT controller.
- the machine learning technique creates at least one boundary of acceptable network traffic behavior.
- Embodiments may also include detecting anomalous behavior by determining a run-time network traffic flow deviates from the at least one boundary of acceptable network traffic behavior.
- Embodiments may also include an anomaly detection engine, the anomaly detection engine including a building anomaly worker model.
- the building model anomaly worker monitors network traffic flows between the plurality of network devices and a controller.
- Embodiments may also include a device anomaly worker model.
- the device anomaly worker model monitors network traffic flows between a network device from the plurality of network devices and the controller.
- Embodiments may also include detecting an anomalous behavior based at least in part on an anomalous behavior alert from each of the building model and the device model.
- Embodiments of the present disclosure may also include a system for anomalous behavior detection, the system including a first network device dl.
- the first network device is positioned in a first building B 1.
- Embodiments may also include a second network device d3.
- the second network device is positioned in a second building B2.
- Embodiments may also include an loT controller.
- the loT controller is operable to receive each of a first network flow fldl from the first network device and a first network flow fld3 from the second network device.
- Embodiments may also include a transmit each of a network flow f2dl to the first network device and a network flow f2d3 from the second network device.
- Embodiments may also include a dispatcher operable to receive flow telemetry and a formal model, the dispatcher featuring at least a building model anomaly worker model MB1.
- the building model anomaly worker MB1 monitors at least MB1 network traffic flows fldl and the network flow f2dl for anomalous behavior.
- Embodiments may also include a building model anomaly worker model MB2.
- the building model anomaly worker MB2 monitors at least network traffic flows fld3 and f2d3 for anomalous behavior.
- Embodiments may also include a first device anomaly worker model Mdl.
- the first device anomaly worker model Mdl monitors network traffic flows between the first network device dl and the loT controller for anomalous behavior.
- Embodiments may also include a second device anomaly worker model Md3.
- the first device anomaly worker model Md3 monitors network traffic flows between the second network device d3 and the loT controller for anomalous behavior.
- FIG. 1 depicts an exemplary embodiment of the system architecture of the present invention with formal model generation, policy verification, and rules enforcement and monitoring features.
- FIG. 2 depicts an example of building data represented using Brick schema.
- FIG. 3 depicts a Sankey diagram of a MUD profile for a Steinel people counting camera.
- FIG. 4 depicts a partial illustration of intermediate semantics after combining a MUD profile, network configurations, and Brick schema.
- FIG. 5 depicts a partial illustration of intermediate form of our loT infrastructure.
- FIG. 6A is a graph which depicts a Time-trace or temporal aggregation of traffic exchanged between three device types in an exemplary infrastructure.
- FIG. 6B is a graph depicting aggregated traffic patterns suggestive of either benign network activity and an. attack traffic pattern of beam counters gateway.
- FIG. 7 depicts an exemplary embodiment of a MUD Brick system for anomaly detection in network traffic flows, a sample loT controller that communicates with four devices located in two buildings (two devices in each building) where each device generates two flows (fl and f2) for its network activity.
- FIG. 8 is a graph demonstrating the impact of window size on the performance of anomaly detection arising from a MUD Brick ontology.
- FIG. 9 is a detected instances of an attack on EvolvePlus sensors gateway with 27 % True Positive Rate (TPR).
- FIG. 10 depicts an exemplary method for enforcing network flow rules of a heterogeneous network of devices.
- FIGS. 11 A, 11B, 11C, and 1 ID depict operations that may supplement those shown in FIG. 10 of an example method for enforcing network flow rules of a heterogeneous network of devices.
- Embodiments of the present disclosure addresses critical areas of cyber-security for large-scale loT infrastructure.
- the first critical area that may be addressed is to provide a system and method that automatically generates a formal ontology or formal model of network communications for a connected infrastructure.
- the formal model is made by receiving a description of a physical environment, a device behavior profile of a plurality of network devices, and at least one network configuration input.
- inputs related to a description of a physical environment like a “Brick schema,” such as described by B. Balaji, A. Bhattacharya, G. Fierro, J. Gao, J. Gluck, D. Hong, A. Johansen, J. Koh, J.
- the received device behavior profiles of network devices may include a Manufacturer Usage Description or MUD profile.
- MUD profiles may be provided by the device manufacturer, they may also be generated by employing the techniques described in A Network Device Classification Apparatus and Process (WO2020118376A1) incorporated in its entirety by reference.
- the received network configurations may include, for example, an IP address, port, virtual local area network (VLAN), and/or media access control (MAC) address, among other things.
- VLAN virtual local area network
- MAC media access control
- the second critical area that may be addressed includes the measurement of network activity of device-specific flow rules. Measurements may be used to diagnose the health of network devices using a set of trained anomaly detection models, such as one-class classifiers, each corresponding to a particular type of device and specific building location. In various embodiments, techniques may be employed that can detect attacks with reasonable accuracy of 92.5%. Finally, three types of location-defined network policies (deployment, administrative, and organizational) may be verified using techniques of the present disclosure.
- Embodiments of the present disclosure may combine information from three sources, namely, intended behavior of individual loT devices, physical assets and building data, and network configurations.
- the embodiments of the present disclosure may draw upon emerging frameworks such as the IETF MUD (Internet Engineering Task Force Manufacturer Usage Description) standard that provides an ACL (Access Control List) like language for describing the expected network communications of an loT device (e.g., controllers with which they talk), and Brick, such as described and incorporated in its entirety by reference B. Balaji, A. Bhattacharya, G. Fierro, J. Gao, J. Gluck, D. Hong, A. Johansen, J. Koh, J. Ploennigs, Y.
- Building Data such as Haystack, Brick, and Industry Foundation Classes (IFC)
- IFC Industry Foundation Classes
- Brick is advantageous as: (a) it describes building entities (sensors, equipment, room, floor and many more) and their relationships by abstracting classes and tags; (b) its hierarchical constructs allows to extend the Brick model to express new entities (e.g., Camera can be derived from Sensor); (c) its expressiveness and ease of adaption allow us to build a better query processor; and (d) it uses the Resource Description Framework (RDF) syntax to maintain the system ontology, this enables application developers to interact with the ontology using query-based language (e.g., SPARQL).
- RDF Resource Description Framework
- Brick schema discusses various applications that can benefit from building data such as energy optimization, fault detection, and risk analysis.
- the physical description may include a name for an element within a physical environment, such as a building, a transportation vehicle, infrastructure, or an ecosystem comprising sensors within different physical environments.
- An example of heterogeneous physical environment may be a collection of automobiles, parking structures, recreational areas, restaurants, commercial dwelling units within a downtown urban environment.
- an oil rig, remote control headquarters, and the support maritime equipment and transport vehicles docked, approaching, and departing the rig are another example of an ecosystem of physical environment. It can be advantageous to provide greater clarity to features within the physical environment.
- physical environment descriptors may include a building, a campus, a maritime craft, a rail-based transportation system, an oil refinery, a mining operation, a chemical plant, a nuclear plant, an alternative energy plant, a nursery, an agricultural field, a municipality, a semiconductor foundry, a port, a warehouse, a stadium, or a university campus.
- Physical environment descriptors may include a room name, a sensor, a utility, a building material, a building floor, a building performance, an asset list, a stairwell, an elevator, a structural element, a fire escape, a furniture piece, an available resource, a time restricted use, a temperature setting, a humidity setting, an air quality parameter, an area occupancy, an area dimension, an area usage restriction, a maintenance status, a password, a username, an area access restriction, a status, an occupancy restriction, a door, a window, an architectural floor plan, or an area intended use of the physical environment.
- an HVAC sensor in a bedroom or a carbon monoxide sensor in an engine room can provide insights to a network operator into the types of alerts, system notifications, and behaviors that could be typical for the physical environment. To benefit from these insights, it is helpful to label the physical environment with a descriptor of the physical environment.
- Some non-limiting examples of a description of a physical environment are a room name, a sensor, a utility, a building material, a building floor, a building performance, an asset list, a stairwell, an elevator, a structural element, a fire escape, a furniture piece, an available resource, a time -restricted use, a temperature setting, a humidity setting, an air quality parameter, an area occupancy, an area dimension, an area usage restriction, a maintenance status, a password, a username, an area access restriction, a status, an occupancy restriction, a door, a window, an architectural floor plan, or an area intended use.
- the description of a physical environment may include descriptions like a class and a tag.
- the class and the tag may be used to describe a relationship amongst two or more network devices amongst the plurality of network devices.
- Network devices may be selected from the same class, while the tag associated with the class may describe a common controller connecting two network devices such as two cameras.
- a description of the physical environment is a hierarchical construct of a relationship of at least two network devices based at least in part on a class of each of the two network devices and one or more tags.
- One such example of a hierarchical construct may include a class such as a camera and a subclass sensor.
- a device behavior profile comprises a semantic
- the semantic comprises at least one class and at least one property.
- loT devices As opposed to general-purpose computers, loT devices have a limited and recognizable pattern of communications. Such a pattern of device communications may be captured as a set of machine-readable constructs describing a network flow of the network device.
- MUD Manufacturer Usage Description
- MUD Manufacturer Usage Description
- a device behavior profile of a network device such as a MUD may be requested, for example from a manufacturer database, a network owner, or a 3 rd party repository storing MUD compliant behavior profiles, and received once the network device has been discovered.
- a MUD profile may be developed by recording network behavior, such as disclosed in the inventors’ work in patent application publications W02020118376A1, W02020118377A1, and W02020118375A1; the contents of which are incorporated in their entirety by reference.
- Network device MUD profiles can be developed and/or received by the cybersecurity system for a number of devices, such as those for a security camera, a thermostat, an occupancy sensor, an HVAC system, a lighting system, an access controller, a fire alarm, a physical security system, a camera, a networked appliance, an industrial device, or a robotic device.
- a valid MUD profile may comprise several access control entries (ACE), serialized in JSON format. Access-lists can be advantageous in that they are explicit in describing the direction of communication, i.e., from device, and to-device. Each ACE would match on source/destination port numbers for TCP/UDP, and type and code for ICMP. The MUD specifications also distinguish local network traffic from Internet communications and provide the support of ambiguities through controller tag which during the deployment system integrators can configure the server location.
- Network Configuration In various embodiments, a Software Defined Network (SDN) network controller and a network switch can be used as at least part of a network monitoring system to identify and classify network flows in real-time at scale.
- SDN Software Defined Network
- Network configuration inputs can be used to pull in network configuration inputs, such as a network address, a port or port number, or VLAN information.
- Network configuration inputs may be received using several techniques, such as by running an IP address retrieval query, such as a SPARQL query.
- IP address retrieval query such as a SPARQL query.
- network configuration inputs may be stored or recorded in a network configuration file that includes information for all the network attached devices.
- a network configuration file may take on many forms, non-limiting examples of which include a spreadsheet or a text file.
- the received network configuration input includes a semantic schema including classes and properties.
- a network topology and traffic distribution can be used in some embodiments to develop and implement an algorithm. Techniques may be used to discover the relevant network devices of nodes in the network topology. Techniques may also be used to determine an appropriate sampling resolution to collect network data during volumetric and distributed attacks.
- a programmable data-plane may be used to develop a scalable telemetry for collecting and analyzing network traffic in real-time. In the present example, programmable switches may be used to create a better defense mechanism against distributed denial-of-service (DDoS) attacks.
- the SDN control plane may accomplish two functions: (a) automatically inserting network rules obtained from the formal ontology, and (b) periodically collecting the activity of network rules for realtime diagnosis by trained inferencing models.
- Static Security Verification MUD profiles are used for verifying the compatibility of an loT device, or networked device, within an organizational network policy for acceptance. Static security verification detects/resolves conflicts among trigger-and-action based policies set by network administrators in loT environments. Trigger and-action-based policies can be used to support MUD access-control rules and building/floor constructs. In one embodiment, a combination of MUD profiles and building Brick schema may be used to verify location- defined network policies for large-scale loT systems.
- Runtime Security Verification MUD specifications can be fed to an IDS (Intrusion Detection System) to detect runtime behaviors that do not conform to what is specified as expected or intended behavior, thereby indicating an anomaly or threat.
- IDS Intrusion Detection System
- MUD may enable enforcement of a baseline security control for loT devices by, for example, isolating exception traffic that does not match the device intended ACEs.
- studies have shown that the attacks are still possible.
- Investigators have used anomaly detection techniques to secure devices by modeling the traffic characteristics of individual devices.
- embodiments of the present disclosure may detect anomalies by looking at the traffic characteristics of both individual devices and a group (based on the group location) of devices in a physical environment, such as a building.
- the elements of the formal model of communications for an loT system and how formal models are generated using the principles of the present invention are described.
- the present invention may allow for static or dynamic security evaluations by applying a system architecture of the present invention to a real loT infrastructure.
- Embodiments of the present disclosure may automatically generate a formal model for the intended behavior of the entire loT system by combining MUD profile of devices, Brick schema of buildings, and network configurations.
- flow rules may be automatically generated and enforced in the network using a programmable control plane.
- Anomaly detection models can then be used to continuously monitor the activity of loT traffic flows at buildinglevel and device-level.
- the compatibility of the loT system behaviors in various embodiments can be systematically checked against, for example, three representative organizational policies, prior to deployment.
- loT infrastructure testbed consisting of twenty (20) loT devices/networked devices of three types (i.e., six units of a people counting camera manufactured by Steinel, twelve units of a beam counter device manufactured by EvolvePlus, two units of license plate recognition cameras manufactured by Nedap) placed across seven physical environments, e.g., buildings across a university campus.
- the trained models that were employed were shown to yield an acceptable system monitoring accuracy of 92.5%.
- a MudBrick 102 may take three sources of information namely building data in the form of Brick schema 104, usage behavior of individual devices in the form of MUD profiles 106, 108, and 110, and their corresponding network configurations 112.
- the linker module 114 may then combine these data sources 104, 106, 108, 110, and 112 and may generate the formal model 116 of the loT system (i.e., system ontology) which is machine -readable and captures data of assets and their relationships.
- data from Brick schema 104 and MUD profiles 106, 108, and 110 may contain formal semantics while the data format of network configurations 112 may vary across different organizations.
- the linker module 114 may be configured to be extensible accepting various formats of configurations.
- the linker module 114 may be of particular importance for its utility in fusing the Brick schema 104, the MUD profiles 106, 108, 110, and network configurations 112 into a system ontology 116.
- the linker module 114 may effectively merge these data sources.
- overlapping data may be merged, some data discarded, while some current schema may be extended.
- one may choose to extend all three schemas or a subset of them, making them fusible.
- two applications may exist that consume the knowledge representation or formal model 116 to enhance the security of the entire infrastructure:
- MudBrick may generate flow rules 118 (in the form of access control lists or ACLs) that may get enforced in operational networks using programmable networking techniques and switches 126.
- the runtime activity of network flow rules 118 may be periodically collected from the network switch 126 and fed to a set of pre-trained anomaly detection models 124, each specific to the controller of devices from a particular type 128 and 130 and their building location 140 and 150 of the university campus 160.
- a static verification application 122 the system ontology 116 can also be checked whether it is compatible with a given set of policies in an organization - such verification may help to identify links (communications), which may violate intended policies 122, and hence, may need to be pruned. This enables enterprise network operators to request the installation team or respective manufacturers to make necessary changes for acceptance.
- the description of a physical environment may be more extensive than the other two schema input types 106, 108, 110 and 112.
- MUD profiles 106, 108, 110 and NETWORK CONFIG 112. These new semantics play the role of "hooks" or adapter to absorb MUD profiles 106, 108, 110 and NETWORK CONFIG 112.
- the existing "Sensor” class is extended in the Brick schema 104.
- FIG. 4 see which "FromDevice” and “ToDevice” properties are extended and class properties are represented.
- the existing class "Equipment” and “sensor” class is extended in the Brick schema, see FIG. 5 for an example.
- Brick schema 104 is a data model that defines the kind of entities (subsystems) in a building 140 and 150 and the relationships among them.
- FIG. 2 depicts the Brick representation 200 for a subset of our loT infrastructure.
- Each node represents either a class or an entity instance, and each edge describes the relationship between nodes.
- Green nodes 210 are classes, which are defined by the original Brick schema and yellow nodes 230, 232, 234 are classes that we have extended by inheriting from an original schema.
- the current version of Brick does not have a definition for cameras, but it provides an extendable hierarchy.
- a people counting camera (steinel _1), manufactured by Steinel [44], is an instance of class “Steinel Counting Camera’’ .
- This device is installed in the eastern room (room _east) on the ground floor (bd > —floor g) of building Bldgl - actual names of buildings and rooms are obfuscated for privacy reasons.
- the counting camera communicates with its controller (steinel crtl 1) which is derived from Brick’s class Equipment.
- the controller is located in room room 4xy at the fourth floor of building Bldg2.
- MUD profile In some embodiments, the network traffic trace of the campus loT infrastructure may be collected, and then the MUD profile may be generated for the three types of devices using a MUDgee tool.
- An exemplary tool is described in A. Hamza, D. Ranathunga, H. Habibi Gharakheili, M. Roughan, and V. Sivaraman, “Clear as MUD: Generating, Validating and Applying loT Behavioral Profiles,” in Proc. ACM loT S&P, Budapest, Hungary, August 2018, and incorporated in its entirety by reference.
- FIG. 3 depicts a visualization of the MUD profile of the Steinel people counting camera.
- the figure depicts the device exposing TCP port 443 and 80 to its controller, the controller periodically communicating with the camera to collect measurements.
- the controller i.e., urn:ietf:params:mud:steinelbroker
- the controller can be provisioned either locally or in a remote network.
- Network In one implementation, we obtained (from our campus IT department) a spreadsheet of network configurations for all connected loT devices and their corresponding controllers in the campus loT system. It contained MAC address, reserved IP address of every device, physical port number they are connected to, their VLAN configurations, and host-names.
- an augmented Brick schema was developed with two semantics (one for MUD and one for network configs), each comprising of classes and properties.
- Such a Brick schema may allow the data from loT MUD profiles with the network configurations and the building metadata to be combined. These semantics can then be used to build a machine-readable knowledge representation of the entire system.
- FIG. 4 depicts the MUD semantics. Two properties were introduced into the system to capture the direction of communication. While the two properties are depicted as FromDevice and ToDevice, they may be substituted as required by a system administrator. These properties may be applied to the class Sensor and point to an ACE class.
- the ACE class may inherit properties from the MUD data - it contains an endpoint to a fixed IP address, domain name or a controller tag.
- the controller tag may be an object derived from the class Sensor or Equipment in Brick.
- semantics may be added to capture all configurations as properties of a Sensor or Equipment. Note that the automatic correlation of these three data sources (i.e., Brick, MUD, network configs) could be challenging since a unique identifier across data sources is required.
- an loT device MAC address is used as the unique key for combining building data and network configurations, and device type was used to combine MUD profiles and building data.
- FIG. 5 visualizes a part of intermediate form (not the semantics).
- the steinel _1 communicates with steinel > _ctrl 1 - protocols, port numbers, VLAN, IP/MAC addresses of the Steinel counting camera and its controller are captured in this form.
- various queries over the ontology can be made.
- the IP address of all cameras located in building Bldgl can be obtained by:
- ⁇ sensor.ip> indicates the returned value and operator (e.g., .type) indicates a property of a given node and a node, in this case, is a class in ontology.
- operator e.g., .type
- MudBrick tools can be developed using a number of technologies.
- the MudBrick tool is developed using Apache Jena, and ran it on a machine with Intel 8 Core CPU 2.7 GHz and 8 GB of RAM on Mac OS X.
- Apache Jena is provided in Apache. (2000) Apache Jena. [Online]. Available: https://jena.apache.org/, which is included in its entirety by reference.
- the loT infrastructure the size of input data sources was 32 KB while MudBrick generated the formal model of size 59 KB.
- a search query (e.g., Listing 1) on average is responded in less than 200 ms.
- a search query (e.g., Listing 1) on average is responded in less than 200 ms.
- Table I shows the impact of devices count and the complexity of their behavior on the size of our formal model and search response time.
- the search response time is consistently kept below 200 ms, even at the largest scale (10000 loT devices and 150 ACLs per device) where the model size reaches to 3200 KB.
- MudBrick may translate the ontology into a set of flow rules (per device) that can be enforced to the network.
- the formal model may allow Internet endpoints to be specified by their domain-name. ACEs pertinent to Internet communications (with domain-name) however cannot be directly translated to flow rules, and hence, need further inspection to infer DNS bindings (mapping DNS names to IP addresses for the various servers/controllers) at run-time. Obviously, ACEs with endpoints specified by IP address may be proactively inserted into the switch - others may be reactively inserted after bindings are determined. Moreover, ACEs obtained from the formal model can be directly translated to flow rules, but they may require a notion of rules priority to tightly enforce the activity of loT devices on the network.
- FIG. 6A depicts the temporal pattern of network traffic (aggregate of all flows) for the three device types in our exemplary infrastructure, between 8am and 1pm on a typical weekday. Note that devices communicate only with their respective controller. Nedap license plate recognition (LPR) cameras, shown by solid blue lines, generate network traffic whenever they detect a moving object (vehicle). The LPR camera is fairly active early in the morning during 8am to 10am transmitting data up to 20 KB per minute to its controller, and its activity slowly becomes infrequent after that - this network behavior matches normal usage of the car park on campus. Steinel cameras, instead, may periodically (shown by dashed lines in FIG.
- LPR Nedap license plate recognition
- the EvolvePlus beam counters gateway which publishes data (count in/out) every minute if there are movements of people, otherwise, it communicates “Hello” messages every 10-minute (shown by red dashed-dotted lines in FIG. 6A). Note that beam counter sensors talk wirelessly to a gateway (in their proximity) which then relays (over Ethernet) aggregate data from connected sensors to a remote controller.
- FIG. 6B we show the change of traffic pattern during an attack on beam counters.
- a frequency jamming attack emulated by manually removing the battery from sensors
- this gateway displays a periodic traffic pattern (normal Hello messages every 10-min) since there is no class scheduled during this period resulting in no movements.
- Focusing on traffic patterns during an attack (as shown in FIG. 6B), a clear anomaly is observed - large spikes of about 5 KB per minute are caused by error messages generated by the gateway due to missing sensors.
- the normal traffic pattern varies over time, and hence a simple thresholding approach would not be sufficient to distinguish normal and anomalous patterns.
- a data-driven models are used to learn the normal behavior of various devices located in different buildings.
- a machine learning technique may be used to determine if the loT infrastructure is affected by a cyber-attack (the “attack detection”), and if so, to determine the contributing building or device (the “attack identification”).
- the attack detection the “attack detection”
- the contributing building or device the “attack identification”.
- one objective is to train the machine with benign traffic profile (one class classifier) of each loT controller, and detect attacks by flagging deviation (from expected pattern) in traffic flows of a controller (obtained from the system ontology).
- FIG. 7 illustrates a high-level structure of our anomaly detection engine. For each loT controller, we can train models at two levels of granularity, namely building level (Stage 1: MBi) and device level (Stage2: Mdk).
- FIG. 7 Structure of our anomaly detection - illustrating a sample loT controller that communicates with four devices located in two buildings (two devices in each building) where each device generates two flows (fl and f2) for its network activity.
- Embodiments of the present disclosure may preserve privacy since the profile is developed from observing network traffic pertaining to the device. Instead of looking into the data to/from the loT device, “meta-data” may be extracted and associated with the network activity of the device at flow levels. Using this meta-data, the behavioral models of devices can be built. Doing so, a temporal sliding window of 60 data-points (byte count of individual flow rule) can be maintained. Several features can be extracted by time-series analysis. In one embodiment, a Wrapper method can be used to select the most important features per each flow. One such example is provided and incorporated in its entirety by reference S. Khalid, T. Khalil, and S.
- Nasreen “A survey of feature selection and feature extraction techniques in machine learning,” in 2014 Science and Information Conference. IEEE, 2014, pp. 372-378.
- the flow-level features are: (1) mean, (2) variance, (3) sum, (4) count above mean, (5) count below mean, (6) the longest strike above mean, (7) the longest strike below mean, (8) zero count, (9) number of peaks, (10) number of time crossing, (11) absolute sum of changes, (12) mean absolute change, (13) hour-of-day, and (14) day-of-week. Note that the total number of features for each model (MBi and Mdk) varies depending on the count of flows per device and count of devices per building.
- Dispatcher This module batches a collection of features (computed on network telemetry) and disseminates them across their corresponding models.
- Stage 1 models are trained by the network behavior of a group of devices that reside in a building.
- the dispatcher obtains situational information (mapping of devices to buildings) from the ontology. As illustrated in FIG. 7, the dispatcher feeds the flow-level features of two devices dl and d2 to their building’s model MBI. Detection of an anomaly at Stagl would activate corresponding Stage2 models where the dispatcher simply presents the features of individual devices to their device models (Mdi) - no situational information is needed for Stage2 inferencing.
- Anomaly Worker Models are used for detecting anomalies in Stages 1 & 2 - these workers are trained by the features of benign traffic (normal) from their respective loT device type, and are able to detect whether a traffic observation belongs to the normal class or not.
- a clustering-based outlier detection algorithm is provided.
- the clustering-based outlier detection algorithm comprises three steps namely, principal component analysis (PCA), Clustering, and Boundary Detection, as shown at the bottom of FIG. 7. For each model (building-level or device-level) we use PCA along with Kaiser method to reduce features count.
- X-Means clustering algorithm (a variant of K-means algorithm, but K is self-tuned) was used first to identify normal clusters, followed by a boundary detection algorithm that identifies the boundary of each cluster.
- attack traffic a number of attacks can be launched.
- three types of attacks were launched.
- An attack on the LPR cameras was simulated by covering the lens to stop normal operation (detecting cars entering/exiting).
- An emulated jamming attack was launched on the beam counters, see FIG. 6B.
- a malware attack against the Steinel cameras was emulated by doubling the rate of pulling data from the camera with the intended objective of exhausting the device battery.
- feature-set- 1 corresponds to the 14 features of individual ACL flows, e.g., HTTP, HTTPS, we identified in ⁇ IV-B
- feature-set-2 corresponds to the same features, but computed on aggregate of ACL flows (one incoming and on outgoing)
- feature-set-3 corresponds to features used for detecting volumetric attacks - this set computes sum, mean, and variance of packet size and count at multiple time-granularities including 2-min, 3-min, 4-min, 8-min, 16-min, and 64-min.
- the feature-set-2 Even though the three feature sets give almost the same overall accuracy (about 92%) the feature-set-2 completely misses attack instances, highlighting the fact that coarse-grained flow telemetry would not be able to tightly model the network behaviors, and hence results in poor visibility. Also, the feature-set-3 is shown to yield a lower TPR (59.5%) compared to the feature-set- 1 (88.0%). The feature-set- 1 provides the best result in terms of attack detection and FPR. This may be due to features-set- 1 capturing more information of the timeseries waveform and detects subtle changes in traffic rates, but features-set-2 fails to capture fine-grained behaviors, hence giving poor performance.
- the feature-set- 1 was able to detect all attack streams with some delays (particularly, early attack instances, closer to the start, went undetected), causing a reduction in TPR.
- the average delay in detecting attacks on license-late recognition (LPR) camera, beam counters (EvolvePlus), and people counting cameras (Steinel) was 55 min, 19 min, and 1 min, respectively.
- the majority (more than 90%) of false-positive alarms do not persist for successive one-minute epochs (intermittent alarms), and hence the risk of mis-classification is low.
- one can reduce the FPR by raising alarms only when an attack persists over successive epochs. For example, expecting persistence over two epochs would reduce the FPR to 5% - this filtering can also lead to a lower TPR, and hence incurring a delay in detecting attacks.
- Stagel only gives a better result (97.5% TPR). However, it does not provide any information on which device is involved in the attack.
- Another reason may be due to the delay in detecting attacks as the change in traffic patterns (by our attacks) is not very significant to get detected immediately, or expected traffic rate during certain hours (e.g., between 9am- 11:30am in FIG. 9) is fairly low. Note that one can further enhance the performance of attack detection by using an ensemble method fed by the output of the Stage 1 and Stage2 models described herein.
- policies are typically enforced at run-time and often implemented in the form of “Match” and “Action” pairs - if packet headers match the criteria specified by the policy, then the policy action is applied to the packet.
- Such implementations are reactive and often do not consider the situational context of policies.
- a method to (proactively) verify the compatibility of a formal model with location-defined network policies (predeployment), using semantics is defined.
- policies are leveraged post generation of the system ontology.
- the system ontology is a model of all potential network communications across the loT system.
- the network communications can then be "pruned” based on organizational policies (e.g., restricting access to certain resources to specific operational zones), resulting in a model of expected system behavior.
- organizational policies e.g., restricting access to certain resources to specific operational zones
- pruning is the action taken upon matching the policy condition.
- the model is in the form of a graph showing relationships between devices, their location, and servers/controllers, with directional edges that have attributes (e.g., specifying protocols, ports, and volumes).
- the impact and spread of attacks originating outside or inside the organization can be assessed using the model, as can that of adding new devices or updating firmware in existing devices in the network, by simply resynthesizing the model with the updated information.
- the model therefore, allows evaluation of the system even before it is built, and several “what if’ scenarios can be explored prior to a field trial or real deployment.
- enterprise loT devices typically support multiple communication protocols (e.g., BACnet, Modbus, and HTTP/HTTPS). They may only use a specific protocol when integrated with the building automation system (with variable protocol capabilities). However, selectively disabling unsupported communication protocols is not accommodated by the MUD standard. Instead, the system ontology may be pruned to meet desired deployment policies before it is enforced to the network.
- multiple communication protocols e.g., BACnet, Modbus, and HTTP/HTTPS.
- Administrative Policies These policies are set for administrative purposes.
- An example of such a policy is that devices in a “highly -restricted zone” of a building are not allowed to communicate outside the building.
- a synthesized policy intent of such scenario is stated by:
- P2 loT devices in the MAT Theater (located in MAT building) are not allowed to have any network communication outside the building.
- acl sensor.isFromDevice
- Violating devices include six units of Steinel counting camera and the two Nedap license plate recognition (LPR) cameras since Steinel cameras use HTTP protocol while Nedap cameras use FTP protocol.
- LPR Nedap license plate recognition
- FIG. 10 illustrates a method for enforcing network flow rules of a heterogeneous network of devices according to some embodiments.
- the method at 1010 may include receiving a description of a physical environment.
- the method may include receiving a device behavior profile of a plurality of network devices.
- the method may include receiving at least one network configuration input.
- the method may include translating the received description of the physical environment, the received device behavior profile, and the at least one network configuration input into a formal model.
- the method may include determining network flow rules based at least in part on the formal model.
- the method may include enforcing the network flow rules. In some embodiments, the network flow rules enhance the security of a heterogeneous network of devices.
- FIGS. 11 A, 11B, 11C, and 1 ID show operations that may supplement the operations illustrated in the method of FIG. 10 according to some embodiments of the present disclosure. In particular, FIGS.
- 11A, 1 IB, 11C, and 1 ID illustrates operations 1102 to 1142 that may supplement operations 1010 to 1060 illustrated in FIG. 10.
- the method may include discovering at least one network device.
- the method may include running an IP address retrieval query.
- the method may include running a SPARQL query.
- the method may include receiving a network configuration file of the plurality of network devices.
- the method may include receiving at least one of a spreadsheet or a text file.
- the spreadsheet or the text file of network configurations of the plurality of network devices may be received.
- the method may include receiving a semantic schema.
- the semantic schema includes at least one class and at least one property.
- the method may include combining a semantic of the received description of the physical environment, and a semantic of the received device behavior profile into a machine-readable knowledge representation of the heterogeneous network of devices.
- the method may include combining at least one class and at least one property of the received description of the physical environment with at least one class and at least one property of the received device behavior profile into a machine-readable knowledge representation of the heterogeneous network of devices.
- the method may include receiving a unique identifier for each of the description of the physical environment, the device behavior profile of each of the plurality of network devices, and the at least one network configuration input.
- the method may include correlating unique identifiers for each of the description of the physical environment, the device behavior profile of each of the plurality of network devices, and the at least one network configuration input to create a combined MUD Brick profile.
- the method may include verifying that the formal model is compliant with an organizational policy.
- the method may include identifying a network traffic flow that violates the organizational policy.
- the method may include using a programmable networking technique.
- the method may include verifying an intended system behavior of the network device.
- the method may include periodically collecting network run-time activity from a network switch.
- the method may include employing at least one data-driven model based at least in part on at least one device behavior profile of a plurality of network devices.
- the method may include training a machine learning technique with a benign network traffic profile of an loT controller.
- the machine learning technique creates at least one boundary of acceptable network traffic behavior.
- the method may include detecting anomalous behavior by determining a run-time network traffic flow that deviates from the at least one boundary of acceptable network traffic behavior.
- the method may include applying a machine learning technique to distinguish a normal device network behavior from an anomalous device network behavior.
- the method may include determining anomalous behavior of at least one network device based on the network flows rule.
- the method may include detecting an anomalous behavior based at least in part on an anomalous behavior alert from each of the building model and the device model.
- an implementer may opt for a mainly hardware and/or firmware vehicle; alternatively, if flexibility is paramount, the implementer may opt for a mainly software implementation; or, yet again alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.
- any vehicle to be utilized is a choice dependent upon the context in which the vehicle will be deployed and the specific concerns (e.g., speed, flexibility, or predictability) of the implementer, any of which may vary.
- logic and similar implementations may include software or other control structures suitable to operation.
- Electronic circuitry may manifest one or more paths of electrical current constructed and arranged to implement various logic functions as described herein.
- one or more media are configured to bear a device-detectable implementation if such media hold or transmit a special-purpose device instruction set operable to perform as described herein.
- this may manifest as an update or other modification of existing software or firmware, or of gate arrays or other programmable hardware, such as by performing a reception of or a transmission of one or more instructions in relation to one or more operations described herein.
- an implementation may include special-purpose hardware, software, firmware components, and/or general-purpose components executing or otherwise controlling special-purpose components. Specifications or other implementations may be transmitted by one or more instances of tangible or transitory transmission media as described herein, optionally by packet transmission or otherwise by passing through distributed media at various times.
- implementations may include executing a special-purpose instruction sequence or otherwise operating circuitry for enabling, triggering, coordinating, requesting, or otherwise causing one or more occurrences of any functional operations described above.
- operational or other logical descriptions herein may be expressed directly as source code and compiled or otherwise expressed as an executable instruction sequence.
- C++ or other code sequences can be compiled directly or otherwise implemented in high-level descriptor languages (e.g., a logic-synthesizable language, a hardware description language, a hardware design simulation, and/or other such similar modes of expression).
- block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those having ordinary skill in the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof.
- ASICs Application Specific Integrated Circuits
- FPGAs Field Programmable Gate Arrays
- DSPs digital signal processors
- Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a USB drive, a solid state memory device, a hard disk drive, a Compact Disc (CD), a Digital Video Disk (DVD), a digital tape, a computer memory, etc.; and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link (e.g., transmitter, receiver, transmission logic, reception logic, etc.), etc.).
- a recordable type medium such as a USB drive, a solid state memory device, a hard disk drive, a Compact Disc (CD), a Digital Video Disk (DVD), a digital tape, a computer memory, etc.
- a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link (e.g
- electrical circuitry includes, but is not limited to, electrical circuitry having at least one discrete electrical circuit, electrical circuitry having at least one integrated circuit, electrical circuitry having at least one application specific integrated circuit, electrical circuitry forming a general purpose computing device configured by a computer program (e.g., a general purpose computer configured by a computer program which at least partially carries out processes and/or devices described herein, or a microprocessor configured by a computer program which at least partially carries out processes and/or devices described herein), electrical circuitry forming a memory device (e.g., forms of memory (e.g., random access, flash, readonly, etc.)), and/or electrical circuitry forming a communications device (e.
- a memory device e.g., forms of memory (e.g., random access, flash, readonly, etc.)
- communications device e.
- a data processing system generally includes one or more of a system unit housing, a video display device, memory such as volatile or non-volatile memory, processors such as microprocessors or digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices (e.g., a touch pad, a touch screen, an antenna, etc.), and/or control systems including feedback loops and control motors (e.g., feedback for sensing position and/or velocity; control motors for moving and/or adjusting components and/or quantities).
- a data processing system may be implemented utilizing suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.
- use of a system or method as disclosed and claimed herein may occur in a territory even if components are located outside the territory.
- use of a distributed computing system may occur in a territory even though parts of the system may be located outside of the territory (e.g., relay, server, processor, signal-bearing medium, transmitting computer, receiving computer, etc. located outside the territory).
- a sale of a system or method may likewise occur in a territory even if components of the system or method are located and/or used outside the territory.
- any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being “operably couplable,” to each other to achieve the desired functionality.
- “operably couplable” include but are not limited to physically mateable or physically interacting components, wirelessly interactable components, wirelessly interacting components, logically interacting components, or logically interactable components.
- one or more components may be referred to herein as “configured to,” “configurable to,” “operable/operative to,” “adapted/adap table,” “able to,” “conformable/conformed to,” etc.
- Those skilled in the art will recognize that “configured to” can generally encompass activestate components, inactive-state components, or standby-state components, unless context requires otherwise.
Abstract
Description
Claims
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2022336869A AU2022336869A1 (en) | 2021-08-30 | 2022-08-30 | Combining device behavioral models and building schema for cyber-security of large-scale iot infrastructure |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US202163238755P | 2021-08-30 | 2021-08-30 | |
US63/238,755 | 2021-08-30 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023031804A1 true WO2023031804A1 (en) | 2023-03-09 |
Family
ID=85410907
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2022/058136 WO2023031804A1 (en) | 2021-08-30 | 2022-08-30 | Combining device behavioral models and building schema for cyber-security of large-scale iot infrastructure |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU2022336869A1 (en) |
WO (1) | WO2023031804A1 (en) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160352836A1 (en) * | 2014-02-21 | 2016-12-01 | Hewlett Packard Enterprise Development Lp | Migrating cloud resources |
US20180332053A1 (en) * | 2017-05-15 | 2018-11-15 | Cisco Technology, Inc. | Validating a device class claim using machine learning |
US20190260794A1 (en) * | 2018-02-20 | 2019-08-22 | Darktrace Limited | Cyber security appliance for a cloud infrastructure |
US20200137119A1 (en) * | 2018-10-29 | 2020-04-30 | Johnson Controls Technology Company | Building system with dynamic manufacaturer usage description (mud) files based on building model queries |
WO2020118377A1 (en) * | 2018-12-14 | 2020-06-18 | Newsouth Innovations Pty Limited | Apparatus and process for monitoring network behaviour of internet-of-things (iot) devices |
-
2022
- 2022-08-30 WO PCT/IB2022/058136 patent/WO2023031804A1/en active Application Filing
- 2022-08-30 AU AU2022336869A patent/AU2022336869A1/en active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160352836A1 (en) * | 2014-02-21 | 2016-12-01 | Hewlett Packard Enterprise Development Lp | Migrating cloud resources |
US20180332053A1 (en) * | 2017-05-15 | 2018-11-15 | Cisco Technology, Inc. | Validating a device class claim using machine learning |
US20190260794A1 (en) * | 2018-02-20 | 2019-08-22 | Darktrace Limited | Cyber security appliance for a cloud infrastructure |
US20200137119A1 (en) * | 2018-10-29 | 2020-04-30 | Johnson Controls Technology Company | Building system with dynamic manufacaturer usage description (mud) files based on building model queries |
WO2020118377A1 (en) * | 2018-12-14 | 2020-06-18 | Newsouth Innovations Pty Limited | Apparatus and process for monitoring network behaviour of internet-of-things (iot) devices |
Also Published As
Publication number | Publication date |
---|---|
AU2022336869A1 (en) | 2024-03-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Pahl et al. | All eyes on you: Distributed Multi-Dimensional IoT microservice anomaly detection | |
US11843628B2 (en) | Cyber security appliance for an operational technology network | |
US20190014137A1 (en) | IoT DEVICE SECURITY | |
US20210273953A1 (en) | ENDPOINT AGENT CLIENT SENSORS (cSENSORS) AND ASSOCIATED INFRASTRUCTURES FOR EXTENDING NETWORK VISIBILITY IN AN ARTIFICIAL INTELLIGENCE (AI) THREAT DEFENSE ENVIRONMENT | |
WO2021171090A1 (en) | An artificial intelligence adversary red team | |
US11641370B2 (en) | Attribute-based policies for integrity monitoring and network intrusion detection | |
Caselli et al. | Specification mining for intrusion detection in networked control systems | |
US20220086064A1 (en) | Apparatus and process for detecting network security attacks on iot devices | |
Pan et al. | Context aware intrusion detection for building automation systems | |
US20200195679A1 (en) | Iot device risk assessment and scoring | |
CN112640381A (en) | Pattern matching based detection in IOT security | |
US20210194815A1 (en) | Telemetry collection and policy enforcement using asset tagging | |
US20230275928A1 (en) | Multi-layered policy management | |
Fuentes-García et al. | Present and future of network security monitoring | |
CA3184265A1 (en) | Endpoint client sensors for extending network visibility | |
US11392115B2 (en) | Zero-trust architecture for industrial automation | |
Hamza et al. | Combining device Behavioral models and building schema for cybersecurity of large-scale IoT infrastructure | |
WO2023239812A1 (en) | Endpoint agents and scalable cloud architecture for low latency classification | |
Graveto et al. | A network intrusion detection system for building automation and control systems | |
Pan et al. | Anomaly behavior analysis for building automation systems | |
WO2023031804A1 (en) | Combining device behavioral models and building schema for cyber-security of large-scale iot infrastructure | |
US11777832B2 (en) | Iterative development of protocol parsers | |
Liu et al. | Machine Learning Based Non-intrusive Digital Forensic Service for Smart Homes | |
US20240015062A1 (en) | Systems and methods for reducing alert fatigue during operation of cyber-physical systems | |
US20230412603A1 (en) | Industrial device mac authentication bypass bootstrapping |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22863749 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2022336869 Country of ref document: AU Ref document number: AU2022336869 Country of ref document: AU |
|
ENP | Entry into the national phase |
Ref document number: 2022336869 Country of ref document: AU Date of ref document: 20220830 Kind code of ref document: A |