System, method, and computer program product for improving network security

Abstract

A network security method comprising using a hardware processor for adding a certain category of synthetic traffic to natural traffic flowing to at least one device in a network which identifies as a device of type T and / or for comparing the device's handling of the synthetic traffic to stored knowledge identifying how devices of type T handle traffic in said certain category, and, accordingly, concluding that the device is / isn't of type T; and / or generating an output indicating that device / s which identify / ies as type T is not of type T as determined by the concluding, to enable network security to prevent the device not of type T as determined by the concluding, from damaging network security by committing malicious activities.

Description

[0001] System, Method, and Computer Program Product for Improving Network Security

[0002] REFERENCE TO CO-PENDING APPLICATIONS

[0003] Priority is claimed from United States Provisional Patent Application No. 63 / 687,046 "Fingerprinting Networked Hardware Assets, Based On Their Respectively Unique Network Behaviors Including ..." - filed August 26, 2024, the disclosure of which application is hereby incorporated herein by reference in its entirety.

[0004] FIELD OF THIS DISCLOSURE

[0005] The present invention relates generally to computerized networks, and more particularly to network security systems configured to secure computer networks such as LANs. BACKGROUND FOR THIS DISCLOSURE

[0006] Cyber-security management platforms, as well as platforms providing network and endpoint visibility and / or threat detection, are available from vendors such as Armis.com, ordr.net, clarity.com, nozominetworks.com.

[0007] State-of-the-art technologies in similar fields are described inter alia in: US2012163212(Al) - APPARATUS AND METHOD FOR DETECTING ABNORMAL TRAFFIC https: / / tinyurl.com / yc3z95ru - Detection of Denial-of-Service Attacks with SNMP / RM0N US11882013(B2) - Network traffic monitoring for anomalous behavior detection US11949695(B2) - Systems and methods for real-time network traffic analysis.

[0008] US 11539717 is a co-owned patent document (aka PHY patent document) describing inter alia a network security system for detecting MAC'less / transparent devices, the system comprising a data repository aka DB, operative to accumulate “fingerprint” data indicative of expected physical level characteristics for each of plural types of switch-device links (aka link types) interconnecting a switch and a hardware device, wherein at least one pair of links of different types differ from one another, at least with respect to the chipset residing in the respective device connected to the respective switch by each respective link; apparatus for reading physical level characteristics of links in at least one network to be protected; and an output device configured to generate alerts of possible presence of a transparent device along at least one link if the physical level characteristics of the at least one link, as read by the apparatus, is anomalous relative to the “fingerprint” data stored in the data repository.

[0009] Conventional active fingerprinting is described here: https: / / medium.com / thg-tech-blog / fingerprinting-network-packets-53ee32ddf07a Any functionality and / or hardware in the above may be used in conjunction with any methods shown and described herein.

[0010] The disclosures of all publications and patent documents mentioned in the specification, and of the publications and patent documents cited therein directly or indirectly, are hereby incorporated by reference other than subject matter disclaimers or disavowals. If the incorporated material is inconsistent with the express disclosure herein, the interpretation is that the express disclosure herein describes certain embodiments, whereas the incorporated material describes other embodiments. Definition / s within the incorporated material may be regarded as one possible definition for the term / s in question.

[0011] Materiality of such publications and patent documents to patentability is not conceded.

[0012] SUMMARY OF CERTAIN EMBODIMENTS

[0013] Certain embodiments are operative for utilizing RM0N1 statistics to “fingerprint” and / or identify and / or classify Ethernet-connected assets.

[0014] Certain embodiments determine the assets’ nature and may not detect attacks carried out , using the network infrastructure as the attack vehicles.

[0015] Certain embodiments utilize RM0N1 statistics for maintaining network health and / or security, and / or performance.

[0016] Certain embodiments use detailed data collected by RMON probes to understand a network environment, which may be web-based, leading to more informed decision-making and / or better network security posture.

[0017] Certain embodiments seek to improve security of an (e.g. web-based) network by fingerprinting networked hardware assets (types and / or classes and / or sub-classes and / or models), instances of which may be nodes on the network, based on their respectively unique network behaviors and typically including their respectively unique packet distribution statistics.

[0018] Certain embodiments seek to confirm, e.g. at a certain confidence level which is typically less than 100%, a suspicion that a certain device (instance of a device) is not what the device claims to be (e.g. the identification of device type implied by the device’s MAC address does not match the traffic-DNA e.g. characteristic packet distribution that the system has stored for that device type does not match the measured situation), where traffic-DNA as measured may include the distribution of packet characteristics (e.g. size) that this device is sending and / or receiving, based on traffic data the system collects for this device (instance).

[0019] The invention includes but is not limited to the following embodiments:

[0020] Embodiment al . A network security method and / or system including detecting and / or identifying and / or validating specific hardware assets, typically including providing traffic statistical characteristics and / or packet distribution statistics for at least one hardware asset and, responsively, identifying the asset as legitimate or rogue.

[0021] Embodiment a2. A method and / or system wherein networked hardware assets are fingerprinted, based on their respectively unique network behaviors including their respectively unique Packet distribution statistics.

[0022] Embodiment a3. A method and / or system wherein fingerprinting networked hardware assets comprises generating a fingerprint characterizing all connected assets of a given type, e.g., all assets that share a specific MAC vendor and model prefix. - ! ! [vendor ID and product ID and the terminology peripherals relate to USB which is not relevant for this application.

[0023] Embodiment a4. A method and / or system 3 wherein a data repository stores a fingerprint for each of many types of networked hardware assets.

[0024] Embodiment a5. A method and / or system 4 wherein the data repository grows as the system herein encounters new types of networked hardware assets.

[0025] Embodiment a6. A method and / or system wherein at least one data packet, from which the packet distribution statistics are derived, is synthesized artificially.

[0026] Embodiment a7. A method and / or system wherein RMON statistics are used to identify the assets.

[0027] Embodiment a8. A method and / or system wherein RMON statistics are used to classify the assets.

[0028] Embodiment a9. A method and / or system wherein RMON 1 probing is used to collect and analyze data packets, thereby providing real-time and historical network statistics about the assets.

[0029] Embodiment alO. Processing circuitry comprising at least one processor and at least one memory, and configured to perform at least one of or any combination of the described operations or to execute any combination of the described modules.

[0030] Embodiment all. Apparatus, method, or computer program product substantially as shown and described herein or substantially as illustrated in any drawings.

[0031] Embodiment al2. Any suitable combination of the embodiments shown herein.

[0032] Certain embodiments seek to identify malicious actors before they even begin to engage in malicious activities e.g. to identify an infected legitimate endpoint that has not yet begun executing malicious activities e.g. a raspberry PI (which may have been placed as a MiTM attack which the system needs to detect) which is in its initial attack stage thus simply awaiting a certain trigger without having yet executed any malicious activity and thus without having been flagged by conventional alerting systems. Yet this malicious device may be flagged by noting that the device is not what it claims to be, thereby providing defenders with a longer timeline to react relative to conventional alerting system and / or enabling defenders to react before the device gets weaponized and actually begins running malicious activities.

[0033] Certain embodiments seek to provide a risk management platform for networks that identifies malicious devices without requiring that the malicious device demonstrate actual malicious activity; this is advantageous given the device’s malicious nature can be discerned before the device even moves into its active phase. Each type of device is typically fingerprinted or profiled, using physical layer data and / or RMON data which is characteristic of that type. Network security is enhanced by identifying the malicious device’s nature early, enabling network security to prevent the device from breaching network security by committing malicious activities, using any suitable policy enforcement and mitigation capabilities that the network and its security mechanism may have.

[0034] Certain embodiments of the present invention seek to provide circuitry typically comprising at least one processor in communication with at least one memory, with instructions stored in such memory executed by the processor to provide functionalities which are described herein in detail. Any functionality described herein may be firmware-implemented or processor- implemented, as appropriate.

[0035] It is appreciated that any reference herein to, or recitation of, an operation being performed is, e.g. if the operation is performed at least partly in software, intended to include both an embodiment where the operation is performed in its entirety by a server A, and also to include any type of “outsourcing” or “cloud” embodiments in which the operation, or portions thereof, is or are performed by a remote processor P (or several such), which may be deployed off-shore or “on a cloud”, and an output of the operation is then communicated to, e.g. over a suitable computer network, and used by, server A. Analogously, the remote processor P may not, itself, perform all of the operations, and, instead, the remote processor P itself may receive output / s of portion / s of the operation from yet another processor / s P', may be deployed off-shore relative to P, or “on a cloud”, and so forth.

[0036] There is thus provided, in accordance with at least one embodiment of the present invention,

[0037] The present invention typically includes at least the following embodiments:

[0038] Embodiment 1.A network security method comprising using a hardware processor for at least one of: adding a certain category of synthetic traffic to natural traffic typically flowing to at least one device in a network which typically identifies as a device of type T; and / or comparing the device’s handling of the synthetic traffic e.g. to stored knowledge identifying how devices of type T handle traffic in the certain category, and, accordingly, concluding that the device is or is not of type T; and / or generating an output indicating that at least one device which identifies as being of type T is in fact, not of type T as determined by the concluding, to enable network security to prevent the device which is not of type T as determined by the concluding, from damaging network security by committing malicious activities.

[0039] A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out all or any subset of the above operations may be provided.

[0040] Embodiment 2. A method according to any embodiment herein, wherein the category of synthetic traffic comprises packets of a certain size.

[0041] Embodiment 3. A method according to any embodiment herein wherein the category of synthetic traffic comprises broken packets.

[0042] Embodiment 4. A method according to any embodiment herein wherein the comparing comprises comparing RMON data characterizing the device’s handling of the synthetic traffic to stored knowledge identifying RMON data which is characteristic of how devices of type T handle traffic in the certain category.

[0043] Embodiment 5. A method according to any embodiment herein, e.g. embodiment 4, wherein the comparing comprises comparing RMON data characterizing output of a device which identifies as a device of type T when packets of a size are fed to the network through a switch port connected to the device, to stored knowledge identifying RMON data which is characteristic of output generated by devices of type T.

[0044] Embodiment 6. A method according to any embodiment herein, e.g. embodiment 4, wherein the comparing comprises determining whether the device which identifies as a device of type T passes broken packets when broken packets are fed to the network through a switch port connected to the device, to stored knowledge indicating how devices of type T handle broken packets including whether or not devices of type T pass broken packets.

[0045] Embodiment 7. A network security method comprising using a hardware processor for at least one of: identifying at least one device in a network as a malicious device, where at least some devices D_l, . . . D_n in the network may identify themselves as being devices of type T_l, . . . T_n respectively, the identifying typically comprising comparing RMON data of at least one device D_i to e.g. stored knowledge identifying RMON data which is characteristic of devices of type T_i, for at least one i = 1, . . .n; and / or accordingly, generating an output indicating that at least one device D_i is suspected to be malicious because D_i’s RMON data is not characteristic of devices of type T_i such that D_i is not, in fact, of type T_i, wherein the output facilitates preventing device D_i from committing malicious activities which damage network security. Embodiment 8. A method according to any embodiment herein e.g. embodiment 7 wherein the RMON data comprises packet size distribution and the output is generated for each device D_i whose packet size distribution is not characteristic of devices of type T_i.

[0046] Embodiment 9. A method according to any embodiment herein, e.g. embodiment 8, wherein the output is generated for each device D_i for which the comparing yields a conclusion, at a level of confidence which exceeds a threshold, that D_i’s packet size distribution differs from the packet size distributions which are characteristic of devices of type T_i.

[0047] Embodiment 10. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the operations of a network security method comprising using a hardware processor for at least one of: identifying at least one device in a network as a malicious device, where at least some devices D_l, . . . D_n in the network identify themselves as being devices of type T_l, ... T_n respectively, the identifying comprising comparing packet size distribution data of at least one device D_i to stored knowledge identifying packet size distribution data which is characteristic of devices of type T_i, for at least one i = 1 , . . . n; and accordingly, generating an output indicating that at least one device D_i is suspected to be malicious because D_i’s packet size distribution data is not characteristic of devices of type T_i such that D_i is not, in fact, of type T_i, wherein the output facilitates preventing device D_i from committing malicious activities which damage network security.

[0048] Embodiment 11. A product according to any embodiment herein e.g. embodiment 10 wherein the packet size distribution data comprises RMON data.

[0049] Embodiment 12. A system implementing the method of any embodiment herein e.g. embodiment 1 or embodiment 7, which may include a hardware processor and memory circuitry (PMC) which may be operatively connected to a hardware-based I / O interface wherein the PMC may be configured to execute any functional modules shown and described herein e.g. in accordance with computer-readable instructions which may be implemented on the non-transitory computer-readable memory in the PMC.

[0050] Also provided, excluding signals, is a computer program comprising computer program code means for performing any of the methods shown and described herein when the program is run on at least one computer; and a computer program product, comprising a typically non- transitory computer-usable or -readable medium e.g. non-transitory computer -usable or -readable storage medium, typically tangible, having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement any or all of the methods shown and described herein. The operations in accordance with the teachings herein may be performed by at least one computer specially constructed for the desired purposes, or a general- purpose computer specially configured for the desired purpose by at least one computer program stored in a typically non-transitory computer-readable storage medium. The term "non-transitory" is used herein to exclude transitory, propagating signals or waves, but to otherwise include any volatile or non-volatile computer memory technology suitable to the application.

[0051] Any suitable processor / s, display and input means may be used to process, display e.g. on a computer screen or other computer output device, store, and accept information such as information used by or generated by any of the methods and apparatus shown and described herein; the above processor / s, display and input means including computer programs, in accordance with all or any subset of the embodiments of the present invention. Any or all functionalities of the invention shown and described herein, such as but not limited to operations within flowcharts, may be performed by any one or more of: at least one conventional personal computer processor, workstation or other programmable device or computer or electronic computing device or processor, either general-purpose or specifically constructed, used for processing; a computer display screen and / or printer and / or speaker for displaying; machine-readable memory such as flash drives, optical disks, CDROMs, DVDs, BluRays, magnetic-optical discs or other discs; RAMs, ROMs, EPROMs, EEPROMs, magnetic or optical or other cards, for storing, and keyboard or mouse for accepting. Modules illustrated and described herein may include any one or combination or plurality of: a server, a data processor, a memory / computer storage, a communication interface (wireless (e.g., BLE) or wired (e.g. ,USB)), a computer program stored in memory / computer storage.

[0052] The term "process" as used above is intended to include any type of computation or manipulation or transformation of data represented as physical, e.g., electronic, phenomena which may occur or reside, e.g., within registers and / or memories of at least one computer or processor. Use of nouns in singular form is not intended to be limiting; thus the term processor is intended to include a plurality of processing units which may be distributed or remote, the term server is intended to include plural typically interconnected modules running on plural respective servers, and so forth.

[0053] The above devices may communicate via any conventional wired or wireless digital communication means, e.g., via a wired or cellular telephone network or a computer network such as the Internet.

[0054] The apparatus of the present invention may include, according to certain embodiments of the invention, machine -readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements all or any subset of the apparatus, methods, features and functionalities of the invention shown and described herein. Alternatively or in addition, the apparatus of the present invention may include, according to certain embodiments of the invention, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any of the teachings incorporated herein ma,y wherever suitable, operate on signals representative of physical objects or substances.

[0055] The embodiments referred to above, and other embodiments, are described in detail in the next section.

[0056] Any trademark occurring in the text or drawings is the property of its owner and occurs herein merely to explain or illustrate one example of how an embodiment of the invention may be implemented.

[0057] Unless stated otherwise, terms such as, "processing", "computing", "estimating", "selecting", "ranking", "grading", "calculating", "determining", "generating", "reassessing", "classifying", "generating", "producing", "stereo-matching", "registering", "detecting", "associating", "superimposing", "obtaining", "providing", "accessing", "setting" or the like, refer to the action and / or processes of at least one computer / s or computing system / s, or processor / s or similar electronic computing device / s or circuitry, that manipulate and / or transform data which may be represented as physical, such as electronic, quantities e.g. within the computing system's registers and / or memories, and / or may be provided on-the-fly, into other data which may be similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices or may be provided to external factors e.g. via a suitable data network. The term “computer” should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, embedded cores, computing system, communication devices, processors (e.g. digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) and other electronic computing devices. Any reference to a computer, controller or processor is intended to include one or more hardware devices, e.g., chips, which may be co-located or remote from one another. Any controller or processor may for example comprise at least one CPU, DSP, FPGA or ASIC, suitably configured in accordance with the logic and functionalities described herein.

[0058] Any feature or logic or functionality described herein may be implemented by processor / s or controller / s configured as per the described feature or logic or functionality, even if the processor / s or controller / s are not specifically illustrated for simplicity. The controller or processor may be implemented in hardware, e.g., using one or more Application-Specific Integrated Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs), or may comprise a microprocessor that runs suitable software, or a combination of hardware and software elements. The present invention may be described, merely for clarity, in terms of terminology specific to, or references to, particular programming languages, operating systems, browsers, system versions, individual products, protocols, and the like. It will be appreciated that this terminology or such reference / s is intended to convey general principles of operation clearly and briefly, by way of example, and is not intended to limit the scope of the invention solely to a particular programming language, operating system, browser, system version, or individual product or protocol. Nonetheless, the disclosure of the standard or other professional literature defining the programming language, operating system, browser, system version, or individual product or protocol in question, is incorporated by reference herein in its entirety.

[0059] Elements separately listed herein need not be distinct components, and, alternatively, may be the same structure. A statement that an element or feature may exist is intended to include (a) embodiments in which the element or feature exists; (b) embodiments in which the element or feature does not exist; and (c) embodiments in which the element or feature exist selectably, e.g., a user may configure or select whether the element or feature does or does not exist.

[0060] Any suitable input device, such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein. Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein. Any suitable processor / s may be employed to compute or generate or route, or otherwise manipulate or process information as described herein and / or to perform functionalities described herein and / or to implement any engine, interface, or other system illustrated or described herein. Any suitable computerized data storage, e.g., computer memory, may be used to store information received by or generated by the systems shown and described herein. Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any other computerized components shown and described herein may communicate between themselves via a suitable computer network.

[0061] The system shown and described herein may include a user interface which may for example include all or any subset of: an interactive voice response interface, automated response tool, speech-to-text transcription system, automated digital or electronic interface having interactive visual components, web portal, visual interface loaded as web page / s or screen / s from server / s via communication network / s to a web browser or other application downloaded onto a user's device, automated speech-to-text conversion tool, including a front-end interface portion thereof and back-end logic interacting therewith. Thus the term user interface or “UI” as used herein includes also the underlying logic which controls the data presented to the user, e.g., by the system display and receives and processes data entered by a user, e.g., using her or his workstation / device.

[0062] BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Certain embodiments of the present invention are illustrated in the following drawings:

[0064] Fig. 1 is a simplified flowchart illustration of a first method provided in accordance with certain embodiments; all or any subset of the operations in Fig. 1 may be provided in practice, in any suitable order, e.g., as shown, all or any subset of the operations in Fig. 1 may be practiced in conjunction with all or any subset of the modules shown and described herein and may be combined with all or any subset of the operations shown and described herein.

[0065] Fig. 2 is a table of example RMON counters.

[0066] Fig. 3 is a table of Ethernet frame components which is useful in understanding typical frame structure, payload , CRC bytes e.g. for the purposes of MiTM detection as described herein.

[0067] Fig. 4 is an example screenshot / wireframe which shows possible scan intervals for various types of environments or various devices in an example user’s network.

[0068] Fig. 5 shows graphs of distribution over various packet size categories, for each of 17 different devices.

[0069] Fig. 6 shows graphs of distribution over various packet size categories, for 4 out of 17 of the devices whose packet size categories are graphed in Fig.5; the 4 devices graphed in Fig. 6 are those which have prefix 682C7B (Cisco IP Phones). In the first or leftmost (“size 65”) column, the highest value belongs to the 3rddevice in the key, the second highest value belongs to the second device in the key, the 3rdhighest or second lowest value belongs to the last or 4thdevice in the key and the lowest value in the leftmost column belongs to the first device in the key.

[0070] Fig. 7a - 7b, taken together, form a simplified flowchart illustration of a second method provided in accordance with certain embodiments; all or any subset of the operations in Figs. 7a - 7b may be provided in practice, in any suitable order e.g. as shown, and may be combined with all or any subset of the operations in Fig. 1. All or any subset of the operations inFigs. 7a - 7b may be practiced in conjunction with all or any subset of the modules shown and described herein and may be combined with all or any subset of the operations shown and described herein.

[0071] Fig. 8 is an example screenshot / wireframe which displays risk indicators according to an embodiment of the invention.

[0072] Figs. 9a - 9e and Fig. 10 show tables useful in understanding certain embodiments.

[0073] Methods and systems included in the scope of the present invention may include some (e.g., any suitable subset) or all of the functional blocks shown in the specifically illustrated implementations by way of example, in any suitable order, e.g., as shown. Computational, functional or logical components described and illustrated herein can be implemented in various forms, for example, as hardware circuits such as but not limited to custom VLSI circuits or gate arrays or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one tangible or intangible computer readable medium and executable by at least one processor, or any suitable combination thereof. A specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question. For example, the component may be distributed over several code sequences such as but not limited to objects, procedures, functions, routines and programs, and may originate from several computer files which typically operate synergistically.

[0074] Each functionality or method herein may be implemented in software (e.g. for execution on suitable processing hardware such as a microprocessor or digital signal processor), firmware, hardware (using any conventional hardware technology such as Integrated Circuit Technology) or any combination thereof.

[0075] Functionality or operations stipulated as being software-implemented may alternatively be wholly or fully implemented by an equivalent hardware or firmware module, and vice-versa. Firmware implementing functionality described herein , if provided, may be held in any suitable memory device and a suitable processing unit (aka processor) may be configured for executing firmware code. Alternatively, certain embodiments described herein may be implemented partly or exclusively in hardware in which case all or any subset of the variables, parameters, and computations described herein may be in hardware.

[0076] Any module or functionality described herein may comprise a suitably configured hardware component or circuitry. Alternatively or in addition, modules or functionality described herein may be performed by a general-purpose computer or more generally by a suitable microprocessor, configured in accordance with methods shown and described herein, or any suitable subset, in any suitable order, of the operations included in such methods, or in accordance with methods known in the art.

[0077] Any logical functionality described herein may be implemented as a real-time application, if and as appropriate, and which may employ any suitable architectural option such as but not limited to FPGA, ASIC, or DSP, or any suitable combination thereof.

[0078] Any hardware component mentioned herein may in fact include either one or more hardware devices, e.g., chips, which may be co-located or remote from one another.

[0079] Any method described herein is intended to include within the scope of the embodiments of the present invention also any software or computer program performing all or any subset of the method’s operations, including a mobile application, platform or operating system e.g. as stored in a medium, as well as combining the computer program with a hardware device to perform all or any subset of the operations of the method.

[0080] Data can be stored on one or more tangible or intangible computer readable media stored at one or more different locations, different network nodes or different storage devices at a single node or location.

[0081] It is appreciated that any computer data storage technology, including any type of storage or memory and any type of computer components and recording media that retain digital data used for computing for an interval of time, and any type of information retention technology, may be used to store the various data provided and employed herein. Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or offline; which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use; and which is based on any suitable technologies such as semiconductor, magnetic, optical, paper and others.

[0082] DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

[0083] "Packets" are used for communication over networks. When, say, an IPhone (or other networked device) wants to send and receive data over the Internet or between devices, a "packet" or network data packet is a unit or chunk of data that is small enough for the IPhone to route as a unit over a network (e.g., over Wi-Fi, cellular, Bluetooth). This occurs, for example, when:

[0084] • Browsing the web (HTTP / HTTPS packets over TCP / IP)

[0085] • Sending messages (via iMessage, WhatsApp, etc.)

[0086] • Streaming music or video (e,g, UDP or TCP, depending on app)

[0087] • Making FaceTime calls

[0088] • Communicating with iCloud e.g. with Apple servers (iCloud sync, Siri, etc.)

[0089] • Sending email (SMTP, IMAP over TCP / IP)

[0090] • Running background services (push notifications).

[0091] Each network data packet used in digital communication includes content aka payload e.g., a piece of a file or message, as well as addressing (e.g. headers) indicating a destination which the content is supposed to reach. A packet may also include a trailer which may include error-checking data like a CRC. Thus each “packet” typically includes a header (routing info, source / destination IP, protocol type) and a payload (the actual data: e.g., portion of an image, video, or text).

[0092] Typically, packets are defined by the protocol stack, based on specific formats at each layer of the networking model. For example, the IPhone’s operating system (iOS) has built-in software that implements the TCP / IP networking model which the OS then uses to send and receive data over a given network such as Wi-Fi, cellular, Bluetooth PAN, e.g., in the course of browsing, streaming, etc. as described above. So, given the TCP / IP stack - a set of layered protocols used by many devices including IPhones, each layer performs its own function, e.g., delivery, addressing, reliability etc., while communicating only with the layers directly above and below, and not with any other layers. Also, in a process known as “encapsulation”, each layer is configured to wrap data from above, in a layer-specific header, typically subject to length fields and framing rules in each protocol. For example, a packet’s IP header may indicate that the packet is (say) 1500 bytes long, the packet’s TCP header may indicate sequence numbers and flags (e.g., SYN, ACK) relevant to the packet etc., and a receiver of the packets reads the headers to parse the packets including where each packet begins and ends.

[0093] Example encapsulation:

[0094] At application layer, Safari creates an HTTP request (say, a request for apple.com). Next is the Transport Layer (TCP wraps it in a segment - which adds a TCP header: port numbers, sequence number, etc. at the Network Layer (IP wraps that in a packet which adds an IP header: source & destination IP addresses; at the Link Layer, Ethemet / Wi-Fi further wraps the packets in a frame which adds a MAC header: local hardware addresses, yielding a final packet ready to be routed over the physical network. Then on the receiving side, each layer peels off its header, in reverse order (order of decapsulation at the receiving end reverses order of encapsulation at the TX end) and passes the remainder of the packet up the stack for further decapsulation by the next layer.

[0095] Not all packets are the same size. Instead, there are many possible packet sizes. This is because different protocols may use different maximum sizes, e.g., for Ethernet (Wi-Fi / LAN) typical max payload is -1500 bytes (MTU - Maximum Transmission Unit), whereas Bluetooth has much smaller packet sizes (e.g., 20-100+ bytes depending on version) and cellular (5G / 4G), say, also has entirely different constraints.

[0096] Also, some protocols such as TCP / IP add their own headers, affecting size. If a large amount of data is transmitted, fragmentation occurs; large pieces of data may be split into plural packets, each of which conforms to the transmission medium’s constraints, even if the data as a whole does not. Sometimes, Dynamic Adaptation occurs, e.g., if IPhones dynamically adjust packet size based on Network quality (e.g. bad connections might result in smaller packets to avoid loss) or application needs (e.g., video streaming may use different strategies than messaging does).

[0097] Packet fragmentation is intended to include any process by which a packet that is too large for some network link’s MTU (Maximum Transmission Unit) is split up to enable the packet to traverse that link; it is appreciated that every link in a network (Ethernet, Wi-Fi, PPP, etc.) typically can carry only up to a certain maximum frame or packet size. If an IP packet’s size (including headers) exceeds the outgoing interface’s MTU, the packet may be dropped unless it is broken up. IPv4 Fragmentation, for example, typically includes: 1. Identification: Each original IPv4 packet is tagged with a 16-bit identification field.

[0098] 2. Flags and Offsets:

[0099] DF (Don’t Fragment) bit: if set, routers must drop the packet, rather than fragment it (and send back an ICMP “Fragmentation Needed” message).

[0100] MF (More Fragments) bit: set on all but the last fragment.

[0101] Fragment Offset: tells the receiver where this fragment belongs in the original pay load (in 8-byte units).

[0102] 3. Router Fragmentation: A router seeing an oversized IPv4 packet and DF=0. may carve it into N smaller fragments, each with its own IP header (same ID, appropriate flags and offsets).

[0103] 4. Reassembly at Destination: host collects fragments (matching ID, source / dest) and uses their offsets to reconstitute the full payload before passing it up to the transport layer.

[0104] In IPv6, routers never fragment. Instead, source fragmentation occurs; the sending host consults Path MTU Discovery to learn the smallest MTU along the path, then splits itself (using a fragment extension header). ICMPv6 “Packet Too Big” guide the sender to lower its packet size.

[0105] While fragmentation advantageously allows too-large, e.g., jumbo or giants or oversize IP packets to cross too-small MTU links, e.g., by splitting the packets into numbered “chunks”, fragmentation does typically add overhead, latency, and security complications such that some networks strive to discover and use an MTU that avoids fragmentation.

[0106] It is appreciated, that typically, fragmentation (e.g., of jumbo packets) does not negate operation of the system; it seems that certain devices fragment jumbo packets in certain ways, and for this reason and / or another, when histograming packet size, the distribution over various “buckets” is still characteristic of the device, even though the bucket may contain a mixture of original less-than-jumbo packets with fragments of jumbo packets.

[0107] In this specification, the term fragmentation is intended to include the mechanism by which, at the IP layer, oversized IP packets are split into fragments (IPv4 at routers or hosts, IPv6 only at hosts) and reassembled at the destination. It is appreciated that no true “fragmentation” occurs at the Ethernet layer, however since at that level, frames that exceed the supported Maximum Transmission Unit (MTU) are simply discarded as “giants” or “too-long” frames, with incrementation of corresponding error counters, with no partial frames being transmitted .

[0108] It is appreciated that if a jumbo-sized Ethernet frame (say 9KB of payload) is put onto a link or toward a NIC that only supports the standard 1500 B MTU, the oversized aka jumbo frame may simply not be accepted, and may be discarded; “Frame too long” (giants) error / s may be provided. Switches and NICs which have hardware limits on maximum frame size and which receive a larger frame they cannot buffer or process, may drop that larger frame and bump a “frame too long” (sometimes called “giants”) counter on that interface.

[0109] At the Ethernet layer there may be no midpoint fragmentation: the frame may never make it up to IP or higher layers. Any application-level segment inside that frame may be lost other than as retransmitted (e.g., TCP may retry).

[0110] Certain Ethernet switches may not, unlike IP routers, generate ICMP messages when discarding oversized frames, and may, instead, simply drop the oversized frames. The loss may be seen at higher layers (e.g., as a stalled TCP connection) and / or in the interface statistics.

[0111] If crossing an IP-routed path with DF=0 (fragmentation allowed), routers may break the packet into MTU-sized pieces, and reassemble at the far end, ensuring a true jumbo frame is never actually sent across a smaller MTU-link. As for IP-level behavior with DF=I (do not fragment), the first router that sees an IP packet larger than the outbound MTU, may drop that larger packet and reply with “ICMP Fragmentation Needed (Type 3, Code 4)”.

[0112] It is appreciated that any oversized Ethernet frame may be dropped at the first nonjumbo hop, resulting in packet loss, retransmissions, and interface error counters rising, typically unless every hop (NIC, switch, router, OS) is explicitly configured to support the jumbo MTU.

[0113] Network traffic may include various sizes of packets depending on, e.g., app, connection type, and protocol.

[0114] Ethernet packet distribution may be used to fingerprint or profile or characterize assets, allowing devices to be detected and / or identified, based entirely or in part on their unique network behavior.

[0115] Each networked asset, which may comprise a particular (model of a) computer or printer, or loT device or other peripheral, typically exhibits distinct patterns when it transmits and / or receives Ethernet packets.

[0116] These patterns are influenced or determined by the device’s hardware, firmware, and software configurations (which may be common to all instances of devices of a particular model such as, say, all instances of a Konica Minolta 224 printer. These patterns may be used as a unique signature that can be used for identification of a device (e.g., for identifying that a particular device is a Konica Minolta 224 printer. By analyzing packet distribution properties — such as frequency and / or size, and / or timing of packets — each asset can be effectively fingerprinted and provide valuable information for rogue devices that spoof legitimate assets or MiTM attacks. This method may enhance network security by enabling identification of authorized devices and / or detecting anomalies and / or identifying potential intrusions, and / or ensuring that only trusted assets are present on the network.

[0117] Examples -

[0118] For a Hiki vision CCTV camera, valid packet values may be between 500 to 1500. Examples of RMON counters (with example values) appear in the table of Fig. b.

[0119] Packets that are too big for the device to handle may be marked as Giants packets.

[0120] Any suitable technology may be employed to gather the relevant information. For example, Remote Network Monitoring (RMON) is a standard specification that facilitates network monitoring and protocol analysis. RM0N1, the first version of this standard, focuses on the physical and data link layers (OSI layers 1 and 2). RM0N1 statistics can be used to monitor and manage network performance and / or identify issues, and / or ensure efficient network operations.

[0121] For example, if there is a hardware issue with the device that causes it to drop a lot of packets (due to many errors) , it may be reflected in the above counters - “Drop events” or “CRC & Align errors”.

[0122] Using RM0N1 statistics for identifying and classifying Ethernet-connected assets enables network administrators to maintain control over and / or visibility of their network environments.

[0123] The information may be gathered using a suitable interface, e.g., SNMP / SSH management interface.

[0124] Example embodiments using RMON statistics to identify and classify Ethernet connected assets are now described in detail.

[0125] It is appreciated that RM0N1, for example, is designed to offer a detailed view of network performance by monitoring Ethernet and Token Ring networks. RM0N1 uses RMON “probes” that collect and analyze data packets, providing real-time and historical network statistics. The RM0N1 standard defines ten MIB groups, each providing specific information elements, or specific types of information, e.g. :

[0126] Real-time LAN statistics, such as utilization, collisions, and errors.

[0127] All the RMON parameters themselves may be considered of “Statistical” nature, and another layer of Grouping / statistical analysis may be added, and any reference herein to “statistics” may be interchanged with “information elements” generally. b. Statistics Group:

[0128] - Functionality: Provides real-time data on network utilization and / or error rates and / or traffic patterns. - Usage: Analyzing this data helps in distinguishing between different types of devices based on their behavior (e.g., servers typically show higher utilization and / or specific error patterns compared to end-user devices.

[0129] The utilization data could be one of indicating parameters in the generated profile / fingerprint / assetDNA parameters. c. Matrix Group:

[0130] - Functionality: Records traffic statistics between pairs of MAC addresses.

[0131] - Usage: traffic statistics between pairs of MAC addresses facilitates understanding of communication patterns between devices, which can be used to classify assets based on their interactions (e.g., identifying devices that frequently communicate with servers and / or gateway devices vs. other devices which communicate with servers and / or gateway devices less frequently or not at all).

[0132] The matrix size may be dependent on the number of assets connected in a given network (different MAC addresses). Specific profile or a given device with another one could be a profile / fingerprint / assetDNA parameter. For example, a certain rogue device may exhibit certain distinct statistics when communicating with a certain server, while a legitimate non-rogue device may exhibit different statistics.

[0133] Fig. 1 is an example flow for the methods and systems herein.

[0134] Anomaly detection and / or clustering may be used for assets that are not familiar (as described later in this document with reference to machine learning.

[0135] Typically, there is a setup or training stage or mapping of the network, so the system knows what behaviors to expect. For example, the system may be configured for generating the DB / Data repository for all assets that are encountered (legitimate and rogue). The real-time traffic statistics may be compared with data from this DB (the identifying key is based on the assets “broadcasted identity” as it is exhibited by its MAC address (the prefix identifies the vendor, and the model).

[0136] Typically, “fingerprint” herein may be interchanged with “profile” and / or with “DNA”.

[0137] The system may not perform packet inspection or look into the traffic itself (protocol and deep packet inspection), and may focus only on packet distribution statistics.

[0138] Typically, the counters are continuously collected, and all counters may be re-set at any given time (as in a stop watch), so one can decide what is the collection period - lOmins, 1 hour, 1 day etc. the system may adjust the timing based on the level of activity, overhead of the switch etc.

[0139] The table of Fig. 2 shows examples of RMON counters. RMON “forcing”

[0140] Certain embodiments involve or assume passive operation, where no external packets are injected to the actual network. However, some embodiments may include a “forcing” mode which may support additional use cases, such as but not limited to:

[0141] Example #1 - If a certain device is suspected as rogue, or being of a certain legitimate type, but do not have enough RMON traffic information, one can synthesize and transmit from that specific switch port a packet of a certain size that may help create additional data.

[0142] Example #2 - Detecting MiTM, - most network stacks may drop “broken packets”, packets that have transmission errors (i.e., CRC). In this approach “broken” packets can be synthesized, then transmitted, and then the RMON counters are monitored , if 5 broken packets are transmitted, but when the counter is read and is 0, this certainly indicates that there is a MiTM (as something must have dropped the packets before they reach the switch).

[0143] Forcing, e.g. as in operation I in Fig. a, may be achieved by any suitable method such as but not limited to (embodiment 1): adding a certain category of synthetic traffic to natural traffic flowing to at least one device in a network which identifies as a device of type T; and / or comparing the device’s handling of the synthetic traffic to stored knowledge identifying how devices of type T handle traffic in the certain category, and, accordingly, concluding that the device is or is not of type T; and / or generating an output indicating that at least one device which identifies as being of type T is in fact, not of type T as determined by the concluding, to enable network security to prevent the device which is not of type T as determined by the concluding, from damaging network security by committing malicious activities.

[0144] The above teachings may be combined with any suitable teachings known in the art such as but not limited to the method for detecting abnormal traffic described in US2012163212 or US 11539717, the disclosures of which are hereby incorporated here within in their entirety, including the method of detecting abnormal traffic by analyzing a traffic image that is generated based on traffic statistics data provided by an external traffic analysis device or an internal traffic analysis device without the need to access a traffic analysis device that is hard to access or manipulate.

[0145] Thus any system described herein may also include apparatus for detecting abnormal traffic, including a traffic image processing unit configured to process a traffic image and / or a comparison image processing unit configured to generate a comparison image for detecting abnormal traffic and store the comparison image; and / or an image comparison unit configured to determine whether there is abnormal traffic by comparing the traffic image and the comparison image. The traffic image processing unit may be further configured to receive traffic statistics data from an external traffic analysis device or an internal traffic analysis device and generate a real-time traffic image based on the received traffic statistics data. The external traffic analysis device may comprise a router device, switch device, or firewall device. The traffic image processing unit may be further configured to receive the traffic statistics data from the external traffic analysis device via a Simple Network Management Protocol (SNMP) interface, Remote Network Monitoring (RMON) interface, or a NetFlow interface.

[0146] RMON counters data can be collected via SNMP or SSH / Telnet.

[0147] The “forcing” is typically a synthesize packet that can be generated by the solution application running on a host or triggered within the switch itself.

[0148] The above teachings may be combined with use of SNMP / RMON for detection of Denial-of-Service Attacks with SNMP / RMON e.g. as described in: https: / / tinyurl.com / vc3z95ru. For example, a Denial of Service (DoS) attack scenario may be examined by any system described herein using an Ethernet switch that supports Remote Monitoring (RMON) and Simple Network Management Protocol (SNMP). Instead of detecting DoS attacks using special software or appliance-based firewall devices, which are not economical, manageable network devices supporting SNMP protocol may be employed, for DOS attack detection, to give traffic information such as byte and packet count level network usage, packet size, and packet transmission error events. These can be polled through RMON, a special Management Information Base (MIB). Also, using RMON data polled from the switch, machine learning algorithms may be used to detect DoS attacks and achieve a high detection rate and low false alarm rate.

[0149] The above teachings may be combined with network traffic monitoring for anomalous behavior detection e.g. as described in US11882013 (B2). For example, “status of a device may change, responsive to detecting an anomaly. A traffic pattern of a device may be monitored across a network. It may be determined that the monitored traffic pattern deviates from an expected traffic pattern of the group of devices by a threshold. Responsive to determining that the devices deviates from the expected traffic pattern, packet data transmitted by the device may be inspected. It may be determined that the inspected packet data transmitted by the device is anomalous. The status of the device may be changed responsive to determining that the packet data transmitted by the device is anomalous”.

[0150] The above teachings may be combined with real-time network traffic analysis, e.g., as described in US 11949695. For example, a system may be provided for detecting malicious traffic flows in a network, which includes a processor which, based on packet information received for a plurality of data packets transmitted over the network, is programmed to calculate inter-arrival times and packet durations for the packets. The processor may also be programmed to filter the packet information to remove noise. The processor may be programmed to generate histogram / s based on packet information and / or inter-arrival times and / or packet durations. In addition, the processor may be programmed to generate a power spectral density estimate based on packet information, inter-arrival times, and / or packet durations. Moreover, the processor may be programmed to analyze the histogram / s and / or power spectral density estimate to detect unexpected data flow / s. Furthermore, the processor may be programmed to report any unexpected data flow / s.

[0151] According to certain embodiments, traffic including at least one packet travelling to or from a certain device, may be synthesized, e.g., by a software component on, say, a given laptop which may form part of the system herein rather than being a native network device. The synthesized traffic may be injected into the network, e.g., if, for example, a given device may be thought to be a certain type of device, however confirming this requires a high enough number of packets of a certain size, whereas in practice, there have been fewer or none packets of this size travelling to or from the device. In this case, traffic of a desired profile may be synthesized, e.g,. in this case, traffic including packets of that certain size which may be sent, say from the given laptop to the given device. The synthesis may be from the switch side or from the end-station side. This may enhance identification of the given device if, for example, it is known that the certain type of device tends to generate a given error pattern, when handling packets of the above certain size.

[0152] Profiling or “fingerprinting” solutions herein are configured to identify malicious packets. The system may use the packets analysis to determine the physical asset characteristics. Examples:

[0153] Example #1 - It is suspected that a certain device is not what it says it is (meaning that its identification, as implied by its MAC address, does not match the traffic-DNA ). It may be assume that this is because the asset exhibited a different behavior for a certain packet size. In order not to wait until such a packet size is encountered, this may be sped up by generating that specific packet, generating more samples of how the asset behaves for that specific packet size, which may strengthen our previous analysis or weaken it - in any case it may be more valid.

[0154] Example #2 - It has been decided that a certain asset is rogue and it is desired to validate this. Those broken packets may be sent, and the asset behavior may be examined. If none of the error packets are reported, this typically means that something dropped them in the middle, which is a very strong indication of an MITM attack. If the error counts are not obtained there may be one of two possibilities - either that the attacker was thorough and made sure that error packets are transferred as well, or this was a false positive, and there is no MITM attack. US2012163212 detects a specific attack - DDOS (bombarding the network with traffic to deny service) using RMON. The system herein is typically not configured to detect attacks, and instead may be configured to “profile” the specific traffic counters and deduce based on that what is the physical asset connected, and if it is aligned with its advertised identity (e.g. its identity as determined by its unique MAC address).

[0155] Any suitable method may be employed to differentiate rogue devices, from, say, a new model of printer that HP just started marketing which the system is unfamiliar with. Typically, this system’s data repository keeps updating on a continuous basis. A comparison may be made to an available statistical model (in case this asset has been profiled before), or through an intercomparison . Example - an asset is unfamiliar (which the system may become aware of, say, because the system cannot find its MAC address prefix and suffix in our data). Responsively, the system may create a statistical traffic model for all assets of that type, this may require a minimum number of assets of that type -perhaps 10-20 samples / instances), and the system may then identify, e.g., using a machine-learning technique, anomaly within this previously unencountered asset.

[0156] It is appreciated that “traffic statistical characteristics" is intended to include identifying characteristics of a statistical distribution or histogram of packets which move, over time, from a given device to / from other devices, such as average size of packet or average time interval between packets.

[0157] While some approaches may use information which is based on device existence, embodiments herein utilize the device’s behavior, and may take advantage of the device communicating with other entities over the network to collect RMON statistics .

[0158] "Packets" are used for communication over networks. When, say, an IPhone (or other networked device) wants to send and receive data over the internet or between devices, a "packet" or network data packet is a unit or chunk of data that is small enough for the IPhone to route as a unit over a network (e.g., over Wi-Fi, cellular, Bluetooth). This occurs, for example, when:

[0159] • Browsing the web (HTTP / HTTPS packets over TCP / IP)

[0160] • Sending messages (via iMessage, WhatsApp, etc.)

[0161] • Streaming music or video (e,g, UDP or TCP, depending on app)

[0162] • Making FaceTime calls

[0163] • Communicating with iCloud, e.g., with Apple servers (iCloud sync, Siri, etc.)

[0164] • Sending email (SMTP, IMAP over TCP / IP)

[0165] • Running background services (push notifications).

[0166] Each network data packet used in digital communication includes content aka payload, e.g., a piece of a file or message, as well as addressing (e.g., headers) indicating a destination which the content is supposed to reach. A packet may also include a trailer which may include error-checking data like a CRC. Thus, each “packet” typically includes a header (routing info, source / destination IP, protocol type) and a payload (the actual data: e.g., portion of an image, video, or text).

[0167] Typically, packets are defined by the protocol stack based on specific formats at each layer of the networking model. For example, the IPhone’s operating system (iOS) has built-in software that implements the TCP / IP networking model which the OS then uses to send and receive data over a given network such as Wi-Fi, cellular, Bluetooth PAN, e.g. in the course of browsing, streaming etc., as described above.

[0168] So, given the TCP / IP stack - a set of layered protocols used by many devices including IPhones, each layer performs its own function e.g. delivery, addressing, reliability etc., while communicating only with the layers directly above and below, and not with any other layers. Also, in a process known as “encapsulation”, each layer is configured to wrap data from above, in a layer-specific header, typically subject to length fields and framing rules in each protocol. For example, a packet’s IP header may indicate that the packet is (say) 1500 bytes long, the packet’s TCP header may indicate sequence numbers and flags (e.g., SYN, ACK) relevant to the packet etc., and a receiver of the packets reads the headers to parse the packets including where each packet begins and ends.

[0169] Example encapsulation:

[0170] At application Layer, Safari creates an HTTP request (say, a request for apple.com). Next is the Transport Layer (TCP wraps it in a segment - which adds a TCP header: port numbers, sequence number, etc. at the Network Layer (IP wraps that in a packet which adds an IP header: source & destination IP addresses; at the Link Layer, Ethemet / Wi-Fi further wraps the packets in a frame which adds a MAC header: local hardware addresses, yielding a final packet ready to be routed over the physical network. Then on the receiving side, each layer peels off its header, in reverse order (order of decapsulation at the receiving end reverses order of encapsulation at the TXend) and passes the remainder of the packet up the stack for further decapsulation by the next layer.

[0171] Not all packets are the same size. Instead, there are many possible packet sizes. This is because different protocols may use different maximum sizes, e.g., for Ethernet (Wi-Fi / LAN) typical max payload is -1500 bytes (MTU - Maximum Transmission Unit) whereas Bluetooth has much smaller packet sizes (e.g., 20-100+ bytes depending on version) and cellular (5G / 4G), say, also has entirely different constraints. Also, some protocols such as TCP / IP add their own headers, affecting size. If a large amount of data is transmitted, fragmentation occurs; the large pieces of data are split into plural packets, each of which conforms to the transmission medium’s constraints, even if the data as a whole does not. Sometimes, Dynamic Adaptation occurs e.g. if IPhones dynamically adjust packet size based on Network quality (e.g., bad connections might result in smaller packets to avoid loss) or application needs (e.g., video streaming may use different strategies than messaging does).

[0172] Thus, network traffic may include various sizes of packets depending on, e.g., app, connection type, and protocol.

[0173] More generally, it turns out that packet size distribution may be a viable method to classify assets aka devices such as, say, IP phones, e.g. based on their network context.

[0174] For example, a dataset , which includes three IP Phones (two from Cisco Systems and one from Yealink Corporation) was analyzed; for each device, the following were collected:

[0175] • MAC Address

[0176] • Category (type of device e.g. based on the device identification of its MAC address (for example: Category = IP Phones)).

[0177] • Vendor

[0178] • Switch Model (reflecting the switch to which the asset was connected)

[0179] This data was obtained from customer environments after enabling packet size distribution logging per port.

[0180] To allow meaningful comparisons between distributions of different assets, packet size distribution was normalized using relative frequency: (Packet Size Bin) / (Total Packet Size Bins) rather than absolute frequency.

[0181] This is shown in the Y-axis of the graph. More specifically, the graph’s Y-axis denotes relative frequency as a function of the various packet size bins shown on the X-axis. The data relates, by way of example, to 3 types of IP phone: two of which are CISCO models (7 and 4 devices of the 2 models, respectively, were tested) and one being a YEALINK model (of which 6 devices were tested). The first string in the graph shows the MAC addresses of those respective devices. As is evident from the graph of Fig. 5 , all IP phones tested exhibited a typical or characteristic packet size distribution.

[0182] The graph of Fig. 6 shows the typical packet-size distribution, and shows the characteristic distribution of each of the Cisco IP Phones.

[0183] The graph of Fig. 6 zooms in on the 4 assets, from among the above assets, which have prefix 682C7B (Cisco IP Phones). Again, the distinct pattern shown in Fig. 6 is indicative that packet-level data may be used not only for asset classification but also for anomaly detection or detection of malicious devices, across a network, e.g. as per the method of Fig. 1 and / or of Figs. 7a - 7b.

[0184] It is appreciated that packet data distributions or histograms may be derived from RMON data. RMON (Remote Monitoring) statistics provide a suitable indication (e.g., cumulative histogram) of packet size distribution on the network being monitored; note a given network’s infrastructure may be connected to IT / OT / IOT. RMON is but one example of a protocol that provides network monitoring and statistics gathering, and other protocols may be supported, e.g., on managed switches and routers. RMON data may include statistics group (group 1) data which typically includes counters that help analyze packet sizes, e.g., all or any subset of those shown in the table of Fig. 10.

[0185] These counters can be accessed using a SNMP query or script from a device (assuming RMON is configured), e.g., via an NMS (like SolarWinds, PRTG, or custom scripts). Typically, RMON data provides a bucketed breakdown of packet sizes (one bucket per range of sizes, e.g., a bucket for packets between 65 and 127 bytes, not one bucket per each possible size).

[0186] Typically, RMON statistics counters are cumulative - they continuously increment from the time the device was last rebooted or the RMON agent was reset. By polling the counters, e.g., RMON statistics at certain, e.g., regular intervals, e.g., every 1 - 5 minutes, data can be obtained by subtraction, regarding a given time-window (subtracting the counters values after the timewindow, from what the values were before the time-window. Thus frequency of polling or sampling cycle determines the size of the time-window.

[0187] For example, for a 5-minute sampling cycle, at Ti = 0 min, etherStatsPkts640ctets = 10000. At T2 = 5 min, etherStatsPkts640ctets = 10500. Conclusion: 500 packets of 64 bytes were seen in the last 5 minutes.

[0188] If continuous, per-minute or per-second stats are desired, a network monitoring system (NMS) can be used that polls the counters on a schedule and / or stores historical values and / or computes deltas and rates. Examples include: SolarWinds, PRTG, Zabbix, Nagios (with plugins), or custom scripts using snmpget / snmpwalk.

[0189] The example screenshot / wireframe of Fig. 4 shows scan intervals for various types of environments or various devices in the user’s network. CRITICAL / HIGH / NORMAL / LOW / OCCASIONAL may be used to tag various environments the customer may have - e.g. if it is critical to get a fast response on an attack in the datacenter, the datacenter environment may be deemed “critical”, whereas if system administrators deem certain remote branches of the network to merit no more than occasional scanning since these remote branches have limited possible “blast effect” even when breached, those branches may be deemed “occasional” or “low” to enable the customer to tune its server utilization more parsimoniously and / or effectively and / or cost-effectively. It is appreciated that “forced traffic” is used herein to include artificial or synthetic traffic introduced to shorten time required to analyze an asset’s handling of a given packet size, relative to the time that would be required if only “organic” traffic were flowing through the network.

[0190] “Forcing” does not require any s / w to be added to each switch in each customer’s network, instead forcing may be implemented through a dedicated fixed agent and / or a temporary script and / or through packets that do not need an agent as described in detail elsewhere herein.

[0191] In forced mode, the system may send a number of synthetic or artificial frames (of a specific size) which (far) exceeds 50, but 50 snapshots of those counters may be read. Example: the system may send lOOframes / min, and poll 1 / min, and after 50 samples, i.e., 50 minutes later, the system has 50*100 frames or packets of a specific size passing through that specific asset.

[0192] Example: a certain device used to spoof a legitimate device has limitations on jumbo packets, but currently there is no jumbo packet-sized traffic; in this case the system may introduce such traffic artificially, to facilitate and / or expedite crossing a threshold certainty which is high enough to reduce false positives as much as possible or as much as is needed, given system requirements. The term “jumbo” as used herein is intended to include packets counted by EtherStatsOversizePkts counter or packets over 1518 bytes or larger than standard MTU or oversized frames.

[0193] It is appreciated that synthetic traffic may also include broken packets, intended to aid in diagnosing malicious devices which often simply drop broken packets, whereas the type of device that the malicious device is professing to be, handles broken packets (or packets which have transmission errors such as, CRC errors) differently (e.g. non-malicious devices of type T may pass on broken packets thus may not simply drop such packets). This is useful in detecting MiTM attacks since most network stacks may drop “broken packets”. Thus, synthesis or forcing of “broken” packets, and subsequent monitoring of RMON counters is useful in rapid detection of MiTM attacks, since, if broken packets are transmitted to a suspect device, yet the device’s RMON counter has a value of 0, this is indicative of an MiTM attack.

[0194] It is appreciated that packet size may be analyzed as a discrete variable or continuous variable. For example, if there are 9K packet size options (e.g. for Standard Ethernet, 1,455 possible packet sizes (from 64 to 1518 bytes) or - with jumbo frames - up to 8,937 possible sizes (if 9000 bytes max), packet size may be analyzed as a continuous variable. However, packet size may be analyzed as a discrete value e.g. if RMON statistics are used, which have only a small number of packet size categories aka buckets, e.g.:

[0195] First bucket - packets exactly 64 bytes long

[0196] Other buckets:

[0197] Packets between 65 and 127 bytes Packets between 128 and 255 bytes

[0198] Packets between 256 and 511 bytes

[0199] Packets between 512 and 1023 bytes

[0200] Packets between 1024 and 1518 bytes

[0201] Packets larger than 1518 bytes

[0202] Packets smaller than 64 bytes (usually malformed)

[0203] Any type of analysis may be used to compare distributions, e.g., to compare shapes (e.g. skew, tails (outliers), and / or peaks (multimodal? bimodal? where the modes / peaks are and their size, extent of equality (single narrow spike)), such as but not limited to all or any subset of:

[0204] A. Histograms

[0205] B. Statistical Tests

[0206] • Kolmogorov-Smirnov test (K-S test): Compares CDFs.

[0207] • Anderson-Darling test: Like KS but gives more weight to tails.

[0208] • Cramer-von Mises test: Another global comparison of distributions.

[0209] • Mann-Whitney U test: Non-parametric test comparing ranks (shape & center).

[0210] • Chi-squared test: Can be used for categorical distributions.

[0211] C. Distance Measures Between Distributions

[0212] • Kullback-Leibler divergence (KL divergence): Measures information loss.

[0213] • Jensen-Shannon divergence: Symmetric version of KL.

[0214] • Earth Mover’s Distance (Wasserstein distance): Measures the “work” needed to transform one distribution into another.

[0215] D. Treat distributions as curves or functions, and compare using functional metrics.

[0216] E. Treating packet size as a continuous variable and using

[0217] • Pattern recognition

[0218] • Comparative shape analysis

[0219] • Modeling trends or summaries.

[0220] F. Visual comparisons (in addition to or instead of histograms)

[0221] • Density plots

[0222] • Q-Q plots (quantile-quantile)

[0223] • CDF plots (cumulative distribution functions)

[0224] G. Tools and methods in statistics and signal processing that can quantify the peaks (modes) of a distribution: how many there are, where they are located, and how prominent they are, such as Mode Estimation where Mode = the most frequent value in a distribution. In continuous data, the system may estimate modes using density estimation, since there may not be exact repeats of certain packet sizes. H. Tools for Peak Detection -

[0225] HA. Kernel Density Estimation (KDE)

[0226] • Smooths the data into a continuous curve.

[0227] • Peaks in the KDE correspond to modes of the distribution.

[0228] • Can be used to count modes and find their locations.

[0229] • Choice of bandwidth affects how many peaks are seen — small bandwidth shows more, large bandwidth smooths them out.

[0230] HB. Dip Test of Unimodality

[0231] • A statistical test for whether a distribution is unimodal or multimodal.

[0232] • Returns a p-value: if small, one can reject the null hypothesis of unimodality.

[0233] HC. Hartigan’s Dip Statistic

[0234] • Measures the maximum difference between the empirical distribution function and the best-fitting unimodal distribution.

[0235] • Commonly used for mode testing.

[0236] I. Mean Shift Clustering or other mode-seeking algorithm which groups data points based on proximity to peaks in the density and may be used for identifying number and / or location of modes.

[0237] J. Kernel Density Estimation Estimates smooth density, yielding peak data e.g. number, location, and height of peaks. k.“Mode-seeking” methods that search for peaks (modes) in a continuous or multimodal distribution, especially when there are multiple local maxima.

[0238] • It is most relevant for continuous or high-resolution data, not simple discrete cases.

[0239] • These methods explore the shape of the underlying data distribution, not just raw frequency counts. l. Counts or tallies of categorical values or integers to identify the most frequent value / s in a given time-window.

[0240] A distribution (e.g. of packet sizes, generated by a given device which may profess to be of type T) that characterizes a current time-window may be compared to the distribution of packet sizes that is known to characterize devices of type T, or, the distribution may be compared to a prior distribution of packet sizes that was measured for previous time-windows since a change in the distribution may also be grounds for an alert.

[0241] According to certain embodiments, the system may provide two separate tests - e.g., if a problem is detected with the PHY characteristics of a given device (e.g., as described in co-owned US 11539717, the disclosure of which is hereby incorporated herewithin in its entirety), so the system alerts, and if, e.g., as described herein, a problem is detected with a device’s RMON data, the system also alerts. Alternatively, there may be interaction / combination / synergy between RMON (or more generally, packet data distribution) and PHY. For example, if a device is flagged both by RMON and (e.g. as described in co-owned US11539717, the disclosure of which is hereby incorporated herewithin in its entirety) by PHY then the level of confidence of the risk indicator may be set higher (than the max of the RMON confidence level and the PHY confidence level). Each category may separately have an AssetDNA PHY anomaly or AssetDNA PacketDist. anomaly respectively.

[0242] It is appreciated that typically sets of text-based instructions used to interact with a computer's operating system or applications. - e.g. CLI (Command Line Interface) commands - include commands which may be run in order to poll the PHY commands, as well as commands which may be run in order to retrieve the packet distribution data, e.g., show interfaces gigabitEthernet 1 / 0 / 1 PHY for PHY data and show controllers ethernet-controller statistics to retrieve packet distribution data.

[0243] Typically, there are classes of devices like phone, server, printer, tablet, laptop, desktop, and there are sub-classes like IP phone vs. video phone, and even within each sub-class, there are many models, e.g., hundreds of different IP phone models available globally; a single vendor may have dozens of models. Any class or union thereof or sub-class or union thereof or model or union thereof may be defined as a category.

[0244] It is appreciated that the data repository may store a fingerprint (including packet distribution, e.g., distribution of packets occurring in each time-window or cycle, e.g., each 1 minute or 10 minute period into (say) the “buckets” defined by the RMON packet size classifications for each class and / or each sub-class and / or each model. Each granularity may be used for various use-cases, e.g., the packet distribution between an IP phone and a server typically differs significantly which may facilitate certain types of alerts.

[0245] According to certain embodiments, a classifier may be trained to classify (dependent variable) each device connected to, say, port P of a given server, as belonging to a certain model / class / sub-class, based on independent variables which may (say) comprise 10 sets of RMON stats accumulated over a 10 minute period by polling once / minute. For example, the system might classify a given device as belonging to a certain class or subclass, then the system might retrieve the discrete probability distributions (into RMON packet-size “buckets”) stored for all models, known to the system, within that class, then identify (e.g. using statistical goodness- of-fit testing tools or libraries) which model’s distribution most closely resembles the given device’s distribution, then if that most-similar model is not the model which the device is professing itself to be, the device may be termed a rogue device.

[0246] It is appreciated that a networked device may claim or profess to be of a certain type, e.g. may identify itself when joining a network, as being, say, of type T, as per the device’s unique MAC address which includes the Vendor prefix, model number and a running sequence number aka serial number, and which the device announces each time it joins a network.

[0247] Typically a MAC (Media Access Control) address is a 48-bit (6-byte) identifier assigned to a network interface card (NIC) whose structure, which is standardized by IEEE, includes recognizable vendor and product information e.g. a Vendor Prefix or OUI aka Organizationally Unique Identifier, which typically has 3 bytes (24 bits) which are assigned by IEEE to a given manufacturer of the network device such as, say, Cisco, thus is intended to identify who made the device. There are also 3 (last) bytes which are a Model / Device Identifier or vendor assigned portion via which the vendor or manufacturer may identify a specific model series or model type or product family and / or encode a serial number aka device number unique to each device and / or some vendors use block allocations for certain product lines and / or embed production date and / or batch codes.

[0248] It is appreciated that in virtualized or software-defined networking, MAC addresses may be locally administered and may not reflect a real vendor OUI.

[0249] Typically, each device manufacturer assigns the MAC address (e.g. at the factory, by burning the MAC address into the device’s network hardware (NIC); the MAC address may be stored in read-only memory (ROM) or firmware but may be overridden in software, temporarily or permanently, e.g., in MAC spoofing in order to impersonate a legitimate device on the network. A device typically announces its MAC address each time it joins a network. For example, in WiFi, when a device probes for networks or connects to a network, the device typically includes its own MAC address in the packets. On open Wi-Fi networks, the MAC is exposed even before connecting, e.g., during scanning and probing. In Ethernet, when a device sends frames, its MAC address is the source address in each frame, e.g., since network switches and routers use this to learn where devices are and build their internal tables. Thus, the router knows which device is which (or what each device professes to be), and assigns internal IP addresses accordingly (via DHCP, e.g.). Since the MAC address is stored in non-volatile memory, it is also normally retained across reboots. It is appreciated that in modern OSes such as iOS, Android, Windows, a device can use randomized MAC addresses for privacy, especially on public Wi-Fi, thus devices may hide their real MAC address.

[0250] Typically, each device (whether USB, through VID / PID or Network device, through MAC address), identifies itself as being of type x, or claim to be of type x e.g. in order to get data from the OS (in the USB case), or to be able to interact with network entities (in the Network case). For example, a USB device which is plugged in, is typically required by the host to perform a handshake with the host, using USB descriptors to declare its type, including all or any subset of: Device class (e.g., Mass Storage, HID, Audio, Printer), Vendor ID (VID), Product ID (PID), manufacturer and product strings. An exception is MAC’less devices, which may never identify themselves as being of any particular type, e.g. , class, sub-class, model etc.) However, these , as a rule, are very limited in their access. For example, a passive tap ear-dropping to a network, does not have a MAC address, and those very simple unmanaged switch-hubs can only switch data passing through them and not create new data, in contrast to manage switches that do have a MAC address and may be accessed directly.

[0251] Typically, the system is configured to find rogue devices (which are type tl but profess to be type t2...) using ai and / or a-priori knowledge may be used, e.g. as per below, to generate “validation tests”, at least for the broad classes (IP, server), at least while the system is still young. Any suitable method may be used to train a suitable AI model. For example, the system may systematically collect and analyze more and more data, through various test setups (which may include a variety of switches and Ethernet connected devices, legitimate and rogue). The system may have a priori samples of what is considered “legitimate” and what is considered “rogue” and what is considered legitimate (e.g. as validated and approved through customer deployment) which allows an AI model to tune and re-align, typically using the a priori samples as labels, training to ensure the correct decision is reached, for those samples whose nature (rogue / legitimate) is explicitly known by the system.

[0252] By way of example, any of the information in the tables of Figs. 9a - 9e may be used as a basis for validation tests and / or generating alarms, which may be used until the system is mature enough to yield an ai model whose confidence level is sufficiently high. Once this occurs, the mature system which relies upon the AI model for generating alarms, may have capabilities which exceed those of the validation tests and / or alarms used by the immature system.

[0253] It is appreciated that faulty cable can affect packet distribution and the system herein is typically operative to overcome / diminish this type of false alarm. For example, the system may, before tagging a given asset as suspicious or rogue, first identify what cable is the asset connected through, and may rule out a situation where all assets connected through this cable are presenting behavior (e.g. RMON stats) which deviate from their respective system-stored fingerprints. Alternatively, or in addition, bad cables may be prevented from causing false positive alerts by having the system prompt users or customers or network administrators to cross two different cabling paths and, accordingly, verify if the alert is persistent with the cable or with the device.

[0254] It is appreciated that identifying a device as suspicious or rogue may be based on RMON statistics (e.g. packet distribution into RMON packet-size “buckets” which deviate from what is expected for that device (e.g. what is expected from a device of the device’s professed type and / or the distribution that this very device historically exhibited) in combination with data from other layers regarding the same device or asset , for example if a certain asset unexpectedly (relative to its type and / or history) tries to communicate with the outer world (as opposed to communicating with other network nodes) through a certain port, or an asset starts sending packets over protocols which that asset is not expected to employ (i.e., an asset professing to be an IP camera is expected to use compressed video protocols, but is not expected to use PCL which is used for printers).

[0255] Typically, the system does not wait until enough packets of size S naturally occur, to enable the system to confirm at a high enough level of confidence, that this asset is indeed exhibiting abnormal behavior (abnormal distribution of packet size, e.g.) for packets of size S (e.g. less packets of this size than would be expected). It is appreciated that what is abnormal for one type of asset may be normal for another type of asset.

[0256] Instead, the system speeds up confirmation (or negation) of this suspicion by generating that specific packet size artificially, yielding samples of how the asset behaves for that specific packet size more rapidly than would occur naturally.

[0257] There are known tools, used for hardware diagnostics and trouble shooting purposes, which can synthesize any packet size such as but not limited to packet crafting tools (software-based) which allow packets of any structure and size to be built and sent e.g.:

[0258] • Scapy (Python-based) o Create and send custom packets of virtually any protocol.

[0259] • hping3 o Command-line oriented TCP / IP packet assembler / analyzer. o Supports crafting TCP, UDP, ICMP, and RAW-IP packets. o Can define exact packet sizes and payloads.

[0260] • Ostinato o GUI-based packet crafter / generator. o Create packets from Layer 2 to Layer 7. o Allows fine control of packet size, rate, content, and sequencing.

[0261] • Pktgen (Linux Kernel Module) o A high-speed packet generator. o Allows setting of packet sizes and testing NIC throughput.

[0262] • Mausezahn o Command-line fast traffic generator. o Can generate malformed packets or simulate network traffic, or network traffic generators / load testing tools designed to stress-test and benchmark network hardware e.g.:

[0263] • Iperf / Iperf3 o Allows specifying buffer size, which indirectly affects packet size.

[0264] • TRex (by Cisco) o Can create streams with custom packet sizes and rates.

[0265] • Spirent / IXIA / Keysight o Hi-end tools for highly precise generating of traffic at specific sizes and rates, or use of Ping with Payload Options e.g.

[0266] • ping -s (Linux / macOS) or ping -1 (Windows) o Can send ICMP packets of a specified size. o Not very flexible, but useful for MTU / path testing.

[0267] Figs. 7a - 7b, taken together, is a simplified flowchart illustration of a second method provided in accordance with certain embodiments; all or any subset of the operations inFigs. 7a - 7b may be provided in practice, in any suitable order e.g. as shown, and may be combined with all or any subset of the operations in Fig. 1. All or any subset of the operations inFigs. 7a - 7b may be practiced in conjunction with all or any subset of the modules shown and described herein and may be combined with all or any subset of the operations shown and described herein. The various operations ofFigs. 7a - 7b may be implemented using any suitable technology, e.g. as follows:

[0268] SETUP OPERATION 1010: Optionally, install software aka agents on certain customer network endpoints (hosts / servers / s witches), e.g., to enable broken packets or other types of enforced traffic to be sent. Alternatively, no software / agent may run on any user machine.

[0269] Example: For broken packets-based detection of MiTM attacks, a fixed agent may be installed on endpoints (e.g., in a host security module for USB security). Alternatively, functionality may be provided without installing an agent, e.g., by having a privileged user log remotely to a given machine, using utilities like “PowerShell” and other scripts to generate those broken packets.

[0270] It is possible to send certain types of traffic without needing to open a specific port on the recipient's system; broadcast traffic, where the message is sent to all devices on a network, and multicast traffic, where the message is sent to a specific group of recipients, are examples of traffic that do not require any specific port to be open on each individual receiving device. Additionally, ICMP traffic, commonly used for network diagnostics like ping, and UDP traffic sent to ports that have already been opened for a TCP connection, can also be sent without explicitly opening a port on the receiving end.

[0271] OPERATION 1020: configure agents separately for each organization using the system, if and as needed. For example, the agents may communicate with the centralized server, e.g., through RESful API over HTTPS, and may on a periodic basis send “I am all OK / Not OK , Is there a message / configuration changes waiting for me?”, this ensures that the 5flow is always from the agent side to the server, which may be considered more secure.

[0272] OPERATION 1030: confidence level for the decision that node x has / has not been compromised (rogue yes / no). Is typically configured by each customer, e.g,. through a suitable Risk Indicator page, e.g., as shown in Fig. 8. Alternatively, all decisions may have the same confidence level. Thus typically, the customer cannot decide upon the specific algorithm threshold settings with regard to packet distribution, but can decide whether or not the customer / organization wants this module to generate alerts or not.

[0273] OPERATION 1040: Each customer’s system administrator may also decide whether to activate the option of synthesizing forced traffic (yes / no - configurable parameter).

[0274] OPERATION 1050: The administrator can also tag certain assets that should be excluded from the activation authorization, e.g. due to their operation continuity sensitivity, to minimize adverse effects on customers’ network performance as a whole.

[0275] OPERATION 1060: Client configures polling cycle timing (typically from a range of possible polling frequencies, e.g., anything from once per minute to once per 10 mins), e.g., by selecting a polling cycle parameter. Typically, all switches in all customer networks are polled each sampling cycle, but polling cycle timing may be set per each switch and / or may be specific to each customer, e.g. customer A may poll its switches 1 / min, customer B may poll its switches every 10 min, and customer C may configure to poll switches in its key facility every 3 mins and switches in its peripheral facilities only every 5 minutes. More generally, key infrastructure assets may be scanned more frequently (e.g., datacenter compared with remote branches). Default may be polling every 5 minutes (say).

[0276] OPERATION 1070: Accordingly, poll each switch in the network periodically, e.g., each 1 -5 minutes, typically including running a sequence of commands that retrieve data regarding network assets, e.g., RMON stats indicative of traffic statistics counters and / or PHY layer information (using any suitable technology, e.g., as described in co-owned US11539717, the disclosure of which is hereby incorporated herewithin in its entirety. For example, switch S may be polled and may yield PHY layer information which may include all or any subset of Link status (up / down), Link speed (e.g. 100Mbps, IGbps, lOGbps), Duplex mode (full / half), Port errors (CRC, collisions, input / output errors) for each physical port on the switch, hence for each asset directly connected to switch S through each of switch S’s ports, and / or per-port traffic statistics, which may include all or any subset of Bytes in / out, Errors, Broadcasts, multicasts, unicasts, Packets in / out, Packet discards or drops, Interface utilization, all per-port, thus yielding traffic statistics data for each asset directly connected to switch S through each of switch S’s ports. Typically,, all switches in all customer networks are polled each sampling cycle, where polling cycle timing may be specific to each customer, e.g. , customer A may poll its switches 1 / min (sampling cycle” = 1 min), customer B may poll its switches every 5 min (sampling cycle = 5 min) and customer C may configure to poll certain switches e.g. in its key facility 1 / min and other switches e.g. in its peripheral facilities only every 3 minutes. The terms “polling cycle” and “sampling cycle” may be interchanged in this document.

[0277] The term “sample” is used herein to include any snapshot of various traffic counters, if, for example, the system is configured to require 50 or more samples of relevant data in order to make decisions / reach conclusions and is also configured to poll once every 5 mins, then a packet of interest (e.g. a packet falling within a certain size range) shows up only once every period, 5 X 50 mins may be required to yield 50 datapoints, whereas if packets within the range show up only once every lOmins , double the time may be required. In practice, conclusions e.g. whether a device does, in practice, match its assumed or professed traffic distribution e.g. packet size distribution) may be reached in 10 mins or less (assuming a 1 min cycle (e.g. polling each switch once per minute) which yields 10 data points aka samples at least). If 50 samples are desired, and if traffic is forced, the system may send 10 artificial jumbo-size (say) packets, one per minute thus 10 over a 10 minute period, to a port of a switch which is directly connected to the suspect asset.

[0278] Typically, RMON data can be correlated to a specific device, only when this device is the only one connected to the switch port.

[0279] It is appreciated that there is typically a tradeoff between the server utilization and the sampling cycle of the switches connected to the server since querying the switch for data and analyzing the data consumes CPU and memory). To balance between the HW requirements of the Sepio server on one hand, and the responsiveness on the other hand, the system may “relax” the polling cycle (e.g. polling once every 5mins rather than once every 1 minutes, which allows the switch more idle time in which the switch is not polled); this enables the system to monitor more switches using the same HW setup.

[0280] Any suitable sample size may be used; typically, the method herein determines how large a sampling window to use, depending on how many packets need to be analyzed to determine packet size (say) distribution in order to achieve a certain level of certainty. For example, if a given device has limitation with regards to certain (e.g., large) packet size, then a few may be enough. For example, an older generation loT device may have limited performance, preventing the older device from processing certain very large packet size, as opposed to newer generation devices which are able to process these very large packet sizes. OPERATION 1080: Optionally, the system may allow a user to decide or define level of urgency of identifying asset as rogue which may determine a customer-specific threshold number of packets of size x to analyze before concluding that a certain asset should be marked “rogue”. Or alternatively, the user may decide whether to get alerted yes / no, and if yes, the risk score is fixed over all customers, in which case the threshold number of packets of size x to analyze before concluding that a certain asset should be marked “rogue” is a fixed internal algorithm setting.

[0281] OPERATION 1090: decide whether to introduce forced traffic depending on whether estimated time required till the required number of packets of size x occur naturally, exceeds timeperiod (whether system-determined globally or determined individually by customers) within which decision is desired.

[0282] OPERATION 1100: Typically a packet size distribution (which is characteristic of a given type of asset and typically differs from the packet size distribution which occurs in other types of assets) is stored in a system data repository which “fingerprints” each of a multiplicity of known types of assets. A “fingerprint” is stored when enough data has accumulated, using the requested polling cycle timing and using forced traffic (if so activated) to achieve the confidence level that the system administrator has defined.

[0283] Typically, the characteristic distribution for a given type of asset is derived from data pooled or accumulated from plural networks belonging to plural customers respectively, (many) more than one of which may use the same type of assets. The data from which the characteristic distributions for each type may be accumulated by a system which is securing networks using rogue-ID criteria other than characteristic distributions, and once the system has accumulated enough data to generate characteristic distributions for at least some types of assets (networked devices e.g.), the system may then add departure from characteristic distributions to the rogue-ID criteria the system employs.

[0284] Example: customerl has only one asset of a certain type (such as a certain recently purchased server model x and that one asset is compromised. It may occur that customer2 has 1000 of this server model x which were introduced into customer’s network a year ago. Thus, the system may have high confidence in the packet size distribution believed to be characteristic of all servers which are model X, enabling the system to can easily identify that customerl ’s instance of the model X server has been compromised.

[0285] OPERATION 1110: Alert each time a device’s packet size distribution trends away from its historical packet size distribution at a suitable level of confidence and / or each time a device’s packet size distribution is found to differ from the fingerprint (if known to the system) of the device-type to which the device claims to be. Typically, real time detection is not required. This is because, while a device can be activated or “weaponized” immediately after being introduced into a network to be attacked, which may have required real time detection. However, far more typical, is a rogue or corrupted device which remains inactive (no malicious activity) in a network for months or years before being weaponized. This is due to the effort which may be required to implant such a device (e.g. through recruitment of internal abuser or a hardware supply chain attack), which is only justified if the device then operates for long periods of time, and / or because the attacker desires the network (and possible intrusion detection solutions) to get accustomed to the rogue device before the rogue device becomes actively malicious, since otherwise the rogue device is too easy to identify.

[0286] Typically, no hardware is required in a system according to certain embodiments; a software only solution is feasible, given data is being collected by an existing networking infrastructure, e.g., as described herein.

[0287] Typically, the system has a data repository with stored knowledge of traffic counter statistics profiles (e.g., packet size histograms) which are typical of (hence may be regarded as fingerprints of) for various types of devices respectively; AI / ML may be used to identify new types of devices that the system does not yet have in this repository. Any suitable AI / ML technology (e.g. anomaly detection, clustering, representation learning ) may be used for this input-type discovery tasks e.g. given a repository of known input types and their typical stats, AI / ML can detect or cluster new, unknown input types based on new data samples e.g. by treating the need to expand the data repository to include still -unknown types of devices, as a semisupervised or unsupervised learning problem. The system may flag traffic counter statistics profiles or “inputs” that don't match any of the known types of devices, and group these into emerging unknown types over time. Each input may, for example, be represented by a Feature Vector, typically of fixed-length in which case each input, old or new, is a point in a multidimensional space. A Classifier may be trained on the Known Input Types and supervised learning (e.g., Random Forest, SVM, or Neural Networks) may be used to identify a packet size distribution (say) which can only be matched to any known distribution (of the device types known to the system) at a lower-than-threshold level of confidence (say 30%). Then, the unknown types may be clustered, thereby to identify emerging types of devices using, e.g., unsupervised clustering (e.g., DBSCAN, HDBSCAN, or k-Means) on the feature vectors. Emerging types can be entered into the repository, e.g., when the new cluster is large enough (over- threshold) and / or stable enough over time and / or validated by a human or external analysis, when a new device type is entered, its typical packet size distribution (and / or handling of broken packets) may be stored.

[0288] It is appreciated that any RMON data may be used to generate stored knowledge which is characteristic of various types of devices, respectively; the stored knowledge characteristic of various types of devices need not necessarily include a packet size distribution or cumulative (over time) histogram of packet sizes (from which time-window specific packet size distributions may be derived, e.g., by subtraction of RMON data cumulative over a period which does not include the time-window, from RMON data cumulative over a period which does include the timewindow). Alternatively or in addition, the stored knowledge which is characteristic of various types of devices may include data from the RMON statistics group other than packet size data, and / or may include data from RMON groups other than the statistics group, e.g., the RMON history group, Alarm & Event Groups, Host & HostTopN Groups, Packet Capture Group, etc.

[0289] A particular advantage of embodiments herein is that corrupted or malicious devices on the network need not be detected by identifying malicious activity the devices engage in. Instead, they are detected as described herein e.g. by identifying that a certain device is not what it claims to be and / or what it used to be. Such detection (or any analysis of a malicious device e.g. as described herein) can occur before, even long before, the malicious device is weaponized, e.g. is triggered, and, responsively, initiates malicious activity. This facilitates preventing the malicious device from actually committing malicious activities which damage network security and / or enables network security to prevent the malicious device from damaging network security by committing malicious activities e.g. because the device can be removed (or its network outreach in the organization may be limited) before the device causes any damage at all; the device (e.g. raspberry PI) may have been placed in a network as part of a planned MiTM attack. At the first stage of the attack, the raspberry typically inactively waits for a certain trigger - without executing any malicious activity in the meantime - and this may not be flagged by conventional security systems. According to embodiments herein, the inactive device may be flagged by identifying that the device is not what It claims to be and / or not what it used to be, which facilitates preventing the malicious device from actually committing malicious activities which damage network security and / or enables network security to prevent the malicious device from damaging network security by committing malicious activities by providing an extended timeline for response on the part of system administration where the response may include neutralizing (e.g. by physically or virtually removing the device) and / or limiting the device’s malicious capabilities and / or investigating the device e.g. by provoking some sort of malfunction in the device then watching to see who comes to check on the device.

[0290] Example: given 10 IPhone models distributed by 10 vendors, it may be difficult, slow, or impossible to identify a PHY-characteristic fingerprint which unites all those IPhone, and / or to painstakingly develop a PHY-characteristic fingerprint for each vendor and each model. In contrast, using RMON counters, instead of or in addition to PHY-characteristics, may facilitate or expedite or make it possible to generate an RMON-counter fingerprint in common with all IPhones, thus all 10 products of 10 different vendors may all have a common, uniform fingerprint and / or may expedite development of specific fingerprints for specific vendors / IPhone models, relative to fingerprints based on PHY-characteristics alone. PHY data may include relatively sparse standard information (e.g. Mil registers), plus vendor-specific PHY data, as opposed to a broader span of data that may characterize RMON counters which may be the same across vendors and / or across models.

[0291] It is appreciated that terminology such as "mandatory", "required", "need" and "must" refer to implementation choices made within the context of a particular implementation or application described herewithin for clarity and are not intended to be limiting, since, in an alternative implementation, the same elements might be defined as not mandatory and not required, or might even be eliminated altogether.

[0292] Components described herein as software may, alternatively, be implemented wholly or partly in hardware and / or firmware, if desired, using conventional techniques, and vice-versa. Each module or component or processor may be centralized in a single physical location or physical device or distributed over several physical locations or physical devices.

[0293] Included in the scope of the present disclosure, inter alia, are electromagnetic signals in accordance with the description herein. These may carry computer-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order, including simultaneous performance of suitable groups of operations, as appropriate. Included in the scope of the present disclosure, inter alia, are machine-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order; program storage devices readable by machine, tangibly embodying a program of instructions executable by the machine to perform any or all of the operations of any of the methods shown and described herein, in any suitable order, i.e. not necessarily as shown, including performing various operations in parallel or concurrently rather than sequentially as shown; a computer program product comprising a computer useable medium having computer readable program code, such as executable code, having embodied therein, and / or including computer readable program code for performing, any or all of the operations of any of the methods shown and described herein, in any suitable order; any technical effects brought about by any or all of the operations of any of the methods shown and described herein, when performed in any suitable order; any suitable apparatus or device or combination of such, programmed to perform, alone or in combination, any or all of the operations of any of the methods shown and described herein, in any suitable order; electronic devices each including at least one processor and / or cooperating input device and / or output device and operative to perform e.g. in software any operations shown and described herein; information storage devices or physical records, such as disks or hard drives, causing at least one computer or other device to be configured so as to carry out any or all of the operations of any of the methods shown and described herein, in any suitable order; at least one program pre-stored e.g. in memory or on an information network such as the Internet, before or after being downloaded, which embodies any or all of the operations of any of the methods shown and described herein, in any suitable order, and the method of uploading or downloading such, and a system including server / s and / or client / s for using such; at least one processor configured to perform any combination of the described operations or to execute any combination of the described modules; and hardware which performs any or all of the operations of any of the methods shown and described herein, in any suitable order, either alone or in conjunction with software. Any computer-readable or machine-readable media described herein is intended to include non-transitory computer- or machine-readable media.

[0294] Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any operation or functionality described herein may be wholly or partially computer-implemented, e.g., by one or more processors. The invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally including at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.

[0295] The system may, if desired, be implemented as a web-based system employing software, computers, routers and telecommunications equipment, as appropriate.

[0296] Any suitable deployment may be employed to provide functionalities, e.g., software functionalities shown and described herein. For example, a server may store certain applications, for download to clients, which are executed at the client side, the server side serving only as a storehouse. Any or all functionalities, e.g., software functionalities shown and described herein, may be deployed in a cloud environment. Clients, e.g., mobile communication devices such as smartphones, may be operatively associated with, but external to the cloud.

[0297] The scope of the present invention is not limited to structures and functions specifically described herein and is also intended to include devices which have the capacity to yield a structure, or perform a function, described herein, such that even though users of the device may not use the capacity, they are, if they so desire, able to modify the device to obtain the structure or function.

[0298] Any “if -then” logic described herein is intended to include embodiments in which a processor is programmed to repeatedly determine whether condition x, which is sometimes true and sometimes false, is currently true or false and to perform y each time x is determined to be true, thereby to yield a processor which performs y at least once, typically on an “if and only if’ basis e.g. triggered only by determinations that x is true and never by determinations that x is false.

[0299] Any determination of a state or condition described herein, and / or other data generated herein, may be harnessed for any suitable technical effect. For example, the determination may be transmitted or fed to any suitable hardware, firmware or software module, which is known or which is described herein to have capabilities to perform a technical operation responsive to the state or condition. The technical operation may, for example, comprise changing the state or condition, or may more generally cause any outcome which is technically advantageous given the state or condition or data, and / or may prevent at least one outcome which is disadvantageous given the state or condition or data. Alternatively or in addition, an alert may be provided to an appropriate human operator or to an appropriate external system.

[0300] Applicability of the subject matter disclosed herein is not limited to embodiments claimed nor to solutions for specific disadvantages emphasized herein nor need any element of any system and method described herein, on its own or in combination with other elements described herein, operate only in environments or use-cases or technology areas such as those described herein.

[0301] Features of the present invention, including operations, which are described in the context of separate embodiments, may also be provided in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding process embodiment, and vice versa. Also, each system embodiment is intended to include a server-centered “view” or client centered “view”, or “view” from any other node of the system, of the entire functionality of the system , computer-readable medium, apparatus, including only those functionalities performed at that server or client or node. Features may also be combined with features known in the art, and particularly, although not limited to, those described in the Background section or in publications mentioned therein.

[0302] Conversely, features of the invention, including operations, which are described for brevity in the context of a single embodiment or in a certain order, may be provided separately or in any suitable sub-combination, including with features known in the art (particularly although not limited to those described in the Background section or in publications mentioned therein) or in a different order, "e.g." is used herein in the sense of a specific example which is not intended to be limiting. Each method may comprise all or any subset of the operations illustrated or described, suitably ordered, e.g., as illustrated or described herein.

[0303] Devices, apparatus or systems shown coupled in any of the drawings may, in fact, be integrated into a single platform in certain embodiments, or may be coupled via any appropriate wired or wireless coupling such as but not limited to optical fiber, Ethernet, Wireless LAN, HomePNA, power line communication, cell phone, Smart Phone (e.g. iPhone) which may act as an IPphone, Tablet, Laptop, PDA, Blackberry GPRS, Satellite including GPS, or other mobile delivery. It is appreciated that in the description and drawings shown and described herein, functionalities described or illustrated as systems and sub-units thereof, can also be provided as methods and operations therewithin, and functionalities described or illustrated as methods and operations therewithin can also be provided as systems and sub-units thereof. The scale used to illustrate various elements in the drawings is merely exemplary and / or appropriate for clarity of presentation and is not intended to be limiting.

Claims

CLAIMSLA network security method comprising using a hardware processor for at least one of: adding a certain category of synthetic traffic to natural traffic flowing to at least one device in a network which identifies as a device of type T; comparing the device’s handling of the synthetic traffic to stored knowledge identifying how devices of type T handle traffic in said certain category, and, accordingly, concluding that the device is or is not of type T; andGenerating an output indicating that at least one device which identifies as being of type T is in fact, not of type T as determined by said concluding, to enable network security to prevent the device which is not of type T as determined by said concluding, from damaging network security by committing malicious activities.

2. A method according to claim 1, wherein said category of synthetic traffic comprises packets of a certain size.

3. A method according to any preceding claim wherein said category of synthetic traffic comprises broken packets.

4. A method according to any preceding claim wherein said comparing comprises comparing RMON data characterizing the device’s handling of the synthetic traffic to stored knowledge identifying RMON data which is characteristic of how devices of type T handle traffic in said certain category.

5. A method according to any preceding claim, e.g. claim 4, wherein said comparing comprises comparing RMON data characterizing output of a device which identifies as a device of type T when packets of a size are fed to the network through a switch port connected to said device, to stored knowledge identifying RMON data which is characteristic of output generated by devices of type T.

6. A method according to any preceding claim, e.g. claim 4, wherein said comparing comprises determining whether the device which identifies as a device of type T passes broken packets when broken packets are fed to the network through a switch port connected to said device, to storedknowledge indicating how devices of type T handle broken packets including whether or not devices of type T pass broken packets.

7. A network security method comprising using a hardware processor for at least one of: identifying at least one device in a network as a malicious device, where at least some devices D_l, ... D_n in the network identify themselves as being devices of type T_l, ... T_n respectively, said identifying comprising comparing RMON data of at least one device D_i to stored knowledge identifying RMON data which is characteristic of devices of type T_i, for at least one i = 1, . . .n; and accordingly, generating an output indicating that at least one device D_i is suspected to be malicious because D_i’s RMON data is not characteristic of devices of type T_i such that D_i is not, in fact, of type T_i, wherein the output facilitates preventing device D_i from committing malicious activities which damage network security.

8. A method according to claim 7 wherein said RMON data comprises packet size distribution and said output is generated for each device D_i whose packet size distribution is not characteristic of devices of type T_i.

9. A method according to any preceding claim, e.g. claim 8, wherein said output is generated for each device D_i for which said comparing yields a conclusion, at a level of confidence which exceeds a threshold, that D_i’s packet size distribution differs from the packet size distributions which are characteristic of devices of type T_i.

10. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the operations of a network security method comprising using a hardware processor for at least one of: identifying at least one device in a network as a malicious device, where at least some devices D_l, ... D_n in the network identify themselves as being devices of type T_l, ... T_n respectively, said identifying comprising comparing packet size distribution data of at least one device D_i to stored knowledge identifying packet size distribution data which is characteristic of devices of type T_i, for at least one i = 1, . . .n; and accordingly, generating an output indicating that at least one device D_i is suspected to be malicious because D_i’s packet size distribution data is not characteristic of devices of type T_i such that D_i is not, in fact, of type T_i, wherein the output facilitates preventing device D_i from committing malicious activities which damage network security.

11. A product according to claim 10 wherein said packet size distribution data comprises RMON data.

12. A system implementing the method of any preceding claim e.g. claim 1 or claim 7, which may include a hardware processor and memory circuitry (PMC) which may be operatively connected to a hardware-based I / O interface wherein the PMC may be configured to execute any functional modules shown and described herein e.g. in accordance with computer-readable instructions which may be implemented on the non-transitory computer-readable memory in the PMC.

Images