Patent Grant
11847219
This application claims priority to GB Application No. GB 1908863.2, filed Jun. 20, 2019, under 35 U.S.C. § 119(a). The above-referenced patent application is incorporated by reference in its entirety.
The present invention relates to determining a state of a network having one or more computing devices connected to the network and having access to a set of files.
Ensuring that a network of computing devices is secure is a challenge. Modern computer networks may comprise multiple interconnected networks, each network having a changeable set of coupled computing devices. The networks may be distributed geographically, e.g. in sites all over the world. The computing devices may come in a variety of forms, from blades in a large-scale data warehouse to mobile computing devices to embedded nodes within a sensor network. The proliferation of computing devices has also seen a rise in “bring your own device” behaviour, where users of a network regularly attach their own personal computing devices to the network, as opposed to computing devices that are centrally managed and controlled.
To manage and control a network, it is often desired to obtain an inventory of files that are stored on computing devices within the network. For example, knowing what executable code is present on a coupled computing device may help locate and neutralise security threats with respect to the network, such as malicious code and/or unauthorised access. An inventory may also help with operating system versioning and patching, e.g. help identify computing devices that are susceptible to a particular exploit. A large network may have a huge range of executable code, and exploits may be discovered at a daily or weekly rate. When an exploit is discovered, holes in the security of the network are to be patched as quickly as possible.
However, determining and maintaining an inventory for a computer network at scale is difficult. For example, in the real-world, a large enterprise network may have 500,000 endpoint devices, where the average number of executable files per device may be between 20,000 and 40,000. The number of files that include non-executable files may be much higher. Some devices can have significantly more than this number of files, e.g. local servers may have around 150,000 (or “150 k”) files. In this case, an inventory database accounting for 500 k devices and having 40 k rows of data for each device, would result in 20 k million, or 2×1010, rows of data in a database. Accounting for an average row length of approximately 300 bytes per entry, the storage requirements become 6×1012 bytes or 6,000 gigabytes. Hence, the task quickly becomes intractable, and the scales become larger year-on-year.
Notwithstanding data storage issues, there are also significant network challenges. For example, the state of any network is dynamic, and so data is often collected on a regular basis. However, transferring inventory information from each computing device, e.g. from each of 500 k endpoints coupled to networks of varying size and speed, leads to significant network traffic.
It is therefore desirable to address both the storage and network traffic challenges when attempting to determine a state of a network.
Aspects of the present invention are set out in the appended claims.
Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.
Certain examples described herein relate to efficiently determining a state of a network of computing devices.
A computing device may be, for example, a server computing device, a personal computer, a handheld computer, a communications device such as a mobile telephone or smartphone, a node in a data storage network, a sensor or measurement device such as an embedded Internet-of-Things controller, or another form of information device with computing functionality. Computing devices may include both physical “bare metal” devices and virtual computing devices that are executed within a virtualisation platform upon a physical device. For example, a computer network may have hundreds of computing devices that comprise an operating system that are run as virtual devices within a single server computing device, wherein each virtual computing device has an Internet Protocol address and appears as a separable device upon the network. Mixtures of computing device types are common, e.g. “thin” client terminals may be used to remotely access a server that runs a virtualised client device instance.
A network of computing devices may be connected, as so-called “client” computing devices, to one or more server computing devices in a network computer system. The server computing device may provide services, such as electronic mail, file storage, and application functions. Colloquial reference to electronic services being provided “in the cloud”, typically refers to the access of a server computing device by one or more client computing devices over one or more networks. A server computing device, acting as a server for one set of services, may comprise a client computing device for another set of services. For example, the term “client computing device” as used with reference to the examples herein, refers to clients with respect to an inventory service; as such, a client computing device for the inventory service may comprise a server computing device for a different service, e.g. comprise a file or web server.
Certain examples described herein relate to an inventory of files across a network. The extent of the “network” may be flexibly defined, e.g. as a set of Internet Protocol addresses that are assigned to a particular entity or organisation. The network may comprise a heterogenous set of network equipment installed at different geographical sites. The term “file” refers to a discrete collection of electronic data. In modern computer systems, “files” are presented as discrete items using a file system, which may be implemented by an operating system of the client computing device. In many operating systems, data deemed to be within a file is stored as a one-dimensional array of binary data, typically bytes (e.g. 8 bits). A file may be stored within persistent data storage that is communicatively coupled to a client computing device.
In certain examples, an inventory of at least files comprising executable code may be determined. A file comprising executable code may comprise an executable file, e.g. a file comprising encoded instructions that cause a processor of an executing client computing device to perform a task according to the instructions. The instructions may be “machine code” for processing by a central processing unit (CPU) of a computer and are typically in binary or a related form. In other forms, the instructions may be in a computer script language for interpreting by software. Different operating systems may give executable program files different formats. For example, on Microsoft Windows® systems the Portable Executable (PE) format is used. This format is a data structure that is compatible with the Windows® operating system (OS) for executing the instructions comprised in an executable file. On OS X® and iOS® systems, the Mach-O format is used. Another example is the Executable and Linkable Format (ELF). Different operating systems may also label executable program files with a particular filename extension, for example on the Windows® OS executable program files are typically denoted by the .exe extension. In certain cases, an operating system may use a file that comprises executable code that is arranged to be shared by different executing processes. These are referred to as shared libraries, and within the Windows® OS these are known as dynamic link library (DLL) files. A non-executable file may be seen as a file that is parsed by a separate executable program, e.g. a data file whose contents are accessible via the separate executable program. Certain examples described herein may be applied to both executable and non-executable files.
In certain cases, an inventory of executable software may be constructed. Executable software may form part of system software, e.g. an operating system, and/or one or more application programs. Executable software may comprise a collection of files comprising executable code. Modern computing systems typically have installed on them a variety of executable software. Operating systems may vary by manufacturer, version and level of patching. Application programs may have been chosen by a user or system manager to provide given functionality, e.g. locally or over the network. Executable software is typically stored on, or is accessible by, a computing device for running when desired, to provide its functionality. This software will generally originate from wide variety of sources, i.e. different developers and producers, and may be obtained by different means e.g. downloaded, or installed from disk or drive. In certain cases, an inventory of executable software may be expanded to non-executable files.
Certain examples described herein provide adaptations to a client computing device to obtain data associated with a state of the client computing device, such as data indicating a set of files stored on the client computing device. These files may comprise executable code and/or may comprise data files. Certain examples described herein also provide adaptations to a server computing device to send data to, and/or receive data from, the client computing device to construct an inventory. The inventory may comprise a database populated under the control of the server computing device, where records in the database indicate a state of the client computing device. In this case, the state of the client computing device may comprise an indication of files present on, or accessible to, the client computing device. The server computing device may communicate with a plurality of client computing devices to build up a state of the network, e.g. to determine metadata associated with software and files that are present on the network. The inventory may be used to identify client computing devices that require security patches and/or that contain executable code that may comprise a security risk. The inventory may have many uses, e.g. may enable users of the network to locate multiple copies of a particular file that are spread across the network. The inventory may be used to support versioning, compliance, data storage control, network routing (e.g. peer-to-peer file access), etc.
Each client computing device 110a, 110b includes a data storage device 111a, 111b, which comprises a plurality of files 112a, 112b. The data storage device 111a, 111b may comprise, for example, an electro-mechanical data storage device, such as a hard disk drive, and/or a solid state data storage device. Each client computing device 110a, 110b may comprise a plurality of data storage devices and the data storage devices may be of different types. The one or more data storage devices may be used to implement a physical storage layer, where one or more logical data volumes may be implemented using the physical storage layer.
Each client computing device 110a, 110b also includes a system agent 114a, 114b. The system agent 114a, 114b may comprise computer program code that is processed by one or more processors of the client computing device 110a, 110b. The system agent may operate at a kernel level. The kernel level may be a privileged level of operation, e.g. a similar level to that used by functions of an operating system of the client computing device 110a, 110b. The operating system may control the execution of one or more application programs as well as hardware resources of the computing device. Although, in
In the present example, each system agent 114a, 114b is configured to apply a hash function to binary data read from the plurality of files 112a, 122b to generate a set of data signatures. Each data signature in the set of data signatures may comprise a characterisation of the binary data, e.g. a representation of the binary data having a size that is less than the size of the binary data. The hash function may comprise a one-way function that generates a code for each particular set of binary data, e.g. a code that is dependent on the bit values of the binary data. The code may comprise a fixed-length binary integer that may be represented as an alpha-numeric string, e.g. representing a hexadecimal number. The code may be unique for each particular set of binary data, and/or a particular threshold level of collisions may be defined.
Returning to
The second data interface 122 is configured to access a state database 130. In one case, each record in a set of state records 135 in the state database 130 identifies one of the plurality of client computing devices 110a, 110b and a data signature. Hence, the state records 135 may be seen to indicate the presence of one or more files across the network computer system 100. For example, a record in the state database 130 may comprise a unique identifier for a client computing device and an alpha-numeric code representing the data signature. The unique identifier may comprise one or more of an Internet Protocol (IP) address (e.g. either version 4 or 6), a Media Access Control (MAC) address, and a Basic Input-Output System (BIOS) identifier (e.g. a number or alpha-numeric code stored within solid state memory on a motherboard of the client computing device). The alpha-numeric code may comprise a fixed-length file hash. In other cases, the state database 130 may alternatively store primary key values associated with the client computing devices and the data signatures, e.g. where actual values for the respective identifiers may be determined based on a look-up operation. In these cases, a list of files stored upon a client computing device may be obtained from the state database 130 by filtering records based on a particular device identifier in one column of the database.
In the example of
The server computing device 120 is configured to obtain a set of state bitmaps from data received from the plurality of client computing devices 110a, 110b. For example, the server computing device 120 may receive the data transmitted from each client computing device 110a, 110b over the network 105. In one case, the server computing device 120 may receive several compressed state bitmaps, corresponding respectively to the plurality of client computing devices 110a, 110b, and decompress these to obtain the set of state bitmaps. The server computing device 120 can then use the set of state bitmaps to update the set of state records 135 in the state database 130. For example, if an nth data signature in the set of exemplar data signatures is matched with a generated data signature on a client computing device, the nth bit of the state bitmap may have a value of 1, and this value can be used to add a record to the state database 130, e.g. by adding the identifier of the client computing device and an identifier corresponding to the nth data signature.
Hence, in the example of
In certain examples, the system agent 114a, 114b may be adapted to use a file-system data file 116a, 116b to determine a location of the binary data that is used to generate the data signatures. This may provide further advantages for particular configurations. For example, the system agent 114a, 114b may use a file-system data file 116a, 116b when running in conjunction with certain operating systems. In
Where a file-system data file 116a, 116b is used, the system agent 114a, 114b may be configured to parse the file-system data file 116a, 116b to obtain data locations for the plurality of files 112a, 112b. For example, the plurality of files 112a, 112b may be stored at respective data locations of the data storage device 111a, 111b. The data locations may be represented, e.g. as addresses, in the file-system data file 116a, 116b, for example. The system agent 114a, 114b is configured to generate a set of data signatures from binary data located at the obtained data locations. This may be quicker than scanning a data volume for files and then retrieving data locations based on information stored within the file (e.g. within a file header or the like).
In examples where the file-system data file comprises an MFT, e.g. on an NTFS volume of storage, a fast_file_find function may be implemented to collect metadata directly by parsing the MFT and traversing data runs by block reading the at least one storage volume directly. Parsing the file-system data file 116a, 116b to obtain data locations for the plurality of files 112a, 112b may reduce the overall time required to retrieve and store the data associated with the plurality of files 112a, 112b on the client computing devices 110a, 110b, e.g. may increase the speed at which a set of data signatures may be generated on a client computing device. Using this method may additionally reduce any noticeable adverse effects in performance of the client computing devices 110a, 110b. For example, processor usage at the client computing devices 110a, 110b may not be significantly increased and normal system usage may be negligibly affected by the increase in data storage read rates.
In certain examples, the set of exemplar data signatures may be split into a plurality of sets (or subsets) of data signatures. In these cases, different sets of exemplar data signatures may relate to different expected device configurations. For example, each operating system family may have its own set of exemplar data signatures. Each set of exemplar data signatures may be selectively communicated to the client computing devices, e.g. based on a known build of the client computing device. Alternatively, multiple sets of exemplar data signatures may be sent to a given client computing device; e.g. if a client computing device does not have an operating system that belongs to a particular operating system family, the state bitmap may be mostly or wholly ‘0’ entries, which can be efficiently compressed, e.g. using run-length encoding.
In examples, different approaches may be applied to communicate the set of exemplar data signatures 125 to the client computing devices 110a, 110b. In certain implementations, the set of exemplar data signatures 125 may be communicated using peer-to-peer approaches. For example, the set of exemplar data signatures 125 may be transmitted to a selected one of the plurality of client computing devices 110a, 110b and other ones of the plurality of client computing devices 110a, 110b may obtain the set of exemplar data signatures 125 from the selected one of the plurality of client computing devices 110a, 110b. This process may be repeated, or performed independently, for each set of exemplar data signatures.
For example, system agent 114a, 114b or another system agent may be used to designate one or more of the client computing devices 110a, 110b, e.g. in a subnet of the network 105, to act as a “download master”, e.g. as a peer-to-peer hub for download of the set of exemplar data signatures 125. The designated one or more client computing devices 110a, 110b may obtain and store the set of exemplar data signatures 125 (e.g. and other packages such as software packages) for supply to other computing devices in the respective subnet. This can avoid downloading the set of exemplar data signatures 125 across the network 105 to each of the client computing devices 110a, 110b in each subnet, thereby reducing network traffic.
In the above peer-to-peer approaches, a client computing device 110a, 110b requesting the set of exemplar data signatures 125 (e.g. or another package) may initiate an election, e.g. within a network and/or subnet, to determine which other client computing device 110a, 110b can provide the set of exemplar data signatures 125. A client computing device 110a, 110b having the set of exemplar data signatures 125 may be elected as the download master and the requesting client computing device 110a, 110b may download the package therefrom. In one case, NOMAD® from 1E Limited may be used to implement the peer-to-peer functionality.
In the network computer system 150 of
In the network computer system 150, the switch 123 may be used by the server computing device 120 to communicate with the client computing devices 110a, 110b. For examples, the switch 123 may be used to transmit the set of exemplar data signatures 125 to the client computing devices 110a, 110b as well as requests to obtain a state of the client computing devices 110a, 110b. The switch 123 may also then receive the state bitmaps from the client computing devices 110a, 110b. In one case, the switch 123 may forward data onto the server computing device 120; in another case, the switch 123 may be controlled to execute certain functions without passing data to the server computing device 120, e.g. the switch 123 may update the state database 130 directly under the control of the server computing device 120, e.g. by batching data received from the client computing devices 110a, 110b and performing a data update operation on the state database 130.
In the network computer system 150 of
The client computing device 200 also has a memory 215 comprising, in use, computer program code 214 for a system agent, e.g. the system agent 114a, 114b described in other examples. The memory 215 may be a main memory of the client computing device 200, for example. In examples, the memory 215 comprises random access memory (RAM) and/or read only memory (ROM). The client computing device 200 also has at least one processor 220, e.g. a central processing unit (CPU), configured to execute the computer program code 214 for the system agent. In use, computer program code 214 for the system agent may be retrieved from a persistent data storage device, e.g. from the at least one volume of data storage 211 or another logical volume and loaded into memory for execution by the at least one processor 220. In one case, the system agent may be implemented as a thread upon the at least one processor 220. The system agent may have authorisation from the operating system to access restricted resources, e.g. to access binary data associated with the at least one volume of data storage 211 and/or system files that are used to implement a file system. The system agent may also be authorised to communicate over the network interface 210, e.g. with the server computing device 120 or the switch 123 of
In addition to the components described above, the computing device 200 may include a power supply 201, a Basic Input/Output System (BIOS) 202, one or more buses 204, and input/output (I/O) devices 203. The I/O devices 203 may include human interface devices such as a keyboard and a pointing device. The BIOS 202 may comprise low-level computer program code to boot the client computing device that is stored in a Read Only Memory (ROM). The computing device 200 may also have other components, for example a display driver coupled to a display device. The components may interact with each other via the bus(es) 204, BIOS 202, and I/O devices 203.
The components shown in
In use, e.g. during execution of the computer program code 214, the system agent may be configured to receive, at the network interface 210, a request to obtain a state of the client computing device 200. The request may originate from a server computing device that the client computing device 200 is connected to over the network 205. This may comprise the server computing device 120 or the switch 123 in
On execution of the computer program code 214, and, for example, in response to the request received at the network interface 210, the system agent applies a hash function to binary data read from the plurality of files 212 stored in the at least one volume of data storage 211. As described above, in certain cases, the at least one volume of data storage 211 may comprise a file-system data file, e.g. the file-system data file 116a, 116b according to previous examples, for use in determining the locations of the binary data for each file. For example, the hash function may map the binary data, which may be of arbitrary size, onto data of a fixed size. In other cases, the system agent may perform a scan of the at least one volume of data storage 211 to locate a set of files and access each file in term to determine a location of data associated with the file, e.g. binary data representing the file contents. The system agent applies the hash function to generate a set of data signatures. The hash function may be a fast (e.g. hardware accelerated) hash function available as an operating system service and/or a custom hash function implementation. Applying a hash function may comprise computing a cryptographic function on a set of bit values that represent a given file. The bit values may be provided in a number of different formats, e.g. as hexadecimal data, as a sequence of ‘0’ and ‘1’ values, as a sequence of bytes etc. The data signatures may comprise respective file hashes (or “hash values”, “hash codes”, “digests”). In some cases, the data signatures may comprise derivatives of such file hashes. Each data signature in the set of data signatures may uniquely correspond to a respective file in the plurality of files 212. For example, a given data signature in the set of data signatures may uniquely identify a corresponding file in the plurality of files 212. The generated data signatures and the received exemplar data signatures may then be compared as discussed above.
A set of exemplar data signatures may exploit a redundancy in the number of files that are common to endpoints in the network. In certain cases, multiple sets of exemplar data signatures may be provided. In one case, a group of client computing devices may share many common files, e.g. such files may be components of a given operating system and there may be many endpoints running the same operating system, or the files may comprise shared libraries for common application software which is used across the network. Indeed, even different versions of an operating system, or different operating systems, may share a common set of files, e.g. representing common device drivers and/or a widely used communications stack. These common files may be represented within a given set of exemplar data signatures.
In some cases, state data may comprise the state bitmap as a payload and may also comprise metadata. The state data may be transmitted over the network 205 via the network interface 210 of
The server computing device 300 uses the database interface 330 to access a database 335 representing a state of the network 305. The server 300 may be connected to the network 305, for example, via a network interface 310. The server computing device 300 has data storage 340 to store at least one set of exemplar data signatures 345 resulting from a scan of one or more exemplar computing devices. Each data signature in the set of exemplar data signatures 345 is generated by applying a hash function to binary data representing a file. For example, the MD5 message-digest function may be applied to the contents of the file in order to generate the data signature. The data signature corresponding to the file may comprise the output hash of the file contents, e.g. a “file hash”. In some cases, the data signature may also include metadata in addition to the file hash. Other examples of hash functions include the Secure Hash Algorithm family of standards, e.g. SHA-3, and the RIPEMD (RIPE Message Digest) family of hash functions, e.g. RIPEMD-160.
In
Execution of the computer program code 316 causes the network server to instruct a transmission of the set of exemplar data signatures 345, stored in the data storage 340, to the computing devices over the network. This transmission may be performed as part of a state request or separate to the state request. In one case, the network server may be configured to instruct a transmission of a state request to one or more client computing devices coupled to a network. In one case, the set of exemplar data signatures 345 may be communicated directly from the server computing device 300 to the client computing device 200. In other cases, the set of exemplar data signatures 345 may be indirectly communicated directly to the client computing device 200, e.g. may be communicated by the switch 123 of
After the set of exemplar data signatures 345 have been communicated to one or more client computing devices, the network server obtains state data communicated from these computing devices over the network. The state data may be similar to the state data 530 shown in
The network server, based on execution of the computer program code 316, processes the state data files to extract state bitmaps for the computing devices. This may comprise decoding transmitted data, e.g. decoding any run-length encoding applied to generate the state data. The state bitmaps indicate a presence or absence of each of the set of exemplar data signatures 345, e.g. on a particular computing device of the one or more computing devices coupled to the network 305. For example, a state bitmap associated with a given computing device on the network 305 (e.g. a client device of the server computing device 300) may be indicative of a checklist of data signatures against the set of exemplar data signatures 345, with indications of the data signatures representative of files that are present on the client device, and indications of the data signatures representative of files that are absent on the client device.
The network server, based on execution of the computer program code 316, then updates data records for the database 335 using the state bitmaps. The data records indicate which files are present in each of the computing devices coupled to the network 305. The data records may thus represent the state of the network 305.
In the example of
In the example arrangement of the server computing device 300 shown in
In the example of
The client computing device 110 obtains (steps 702, 703) data signatures for a plurality of files that are stored on at least one volume of data storage 111 accessible to the client computing device 110. For example, the client computing device 110 may access the at least one volume of storage 111 via one or more data access requests sent to the at least one volume of data storage 111 (step 702) in order to obtain the data signatures from the data storage 111 (step 703). Obtaining the data signatures includes applying a hash function to binary data read from the plurality of files. For example, the binary data may be read from data storage locations in the at least one volume of data storage 111 that correspond to the plurality of files. Such reading of the binary data may be done as part of, or in response to, the one or more data access requests sent to the at least one volume of data storage 111. After retrieving the stored binary data, the client computing device 110 can apply the hash function thereto in order to generate the data signatures. For example, as described elsewhere, each data signature may comprise a file hash of the corresponding file. In some cases, the data signature may comprise other data, e.g. metadata, in addition to the actual file hash. The metadata may be extracted from a header of the file.
During a pre-processing operation, and/or while the client computing device 110 is generating a set of data signatures, the server computing device 120 obtains a set of exemplar data signatures resulting from a scan of one or more exemplar computing devices. The scan of the one or more exemplar computing devices may be performed during an initial configuration phase, e.g. as described in more detail below. Each data signature in the set of exemplar data signatures is generated by applying a hash function to binary data from a file in a set of files accessible to the one or more exemplar computing devices. The set of exemplar data signatures may thus be representative of the set of files accessible to the one or more exemplar computing devices.
In
A state bitmap is then generated at the client computing device 110 by comparing the generated data signatures with the set of exemplar data signatures. For example, the state bitmap generated at the client computing device 110 indicates a presence or absence of each data signature, in the set of exemplar data signatures, in the set of generated data signatures which represent the set of files accessible to the client computing device 110. In this way, the set of files accessible to the client computing device 110 on the network can be compared to the (exemplar) set of files accessible to an exemplar computing device, which may be configured in a particular way. This process may be performed in response to one or more of the request at step 701 and the set of exemplar data signatures sent at step 704, or may be performed asynchronously at a scheduled time, e.g. the data signatures may be generated at the client computing device 110 while a CPU is idle.
State data generated from the state bitmap is then transmitted (step 705) from the client computing device 110 over the network. The state data may be a compressed, or otherwise modified, version of the state bitmap generated at the client computing device 110, for example. The server computing device 120 receives (as part of step 705) the state data from each client computing device 110 over the network in response to the initial state request (step 701). The state data is then processed at the server computing device 120 to extract state bitmaps for each of the client computing devices 110. For example, such processing may be to reverse the modification applied to the state bitmaps, e.g. decompressing a compressed version of the set of state data files to extract the individual state data files corresponding to the client computing devices 110 on the network.
The server computing device 120 uses the state bitmaps to update (step 706) a database 130 representing the state of the network. The database 130 comprises data records indicating which files are present in each of the computing devices 100 on the network, as described elsewhere.
In the example of
In one case, the data signature records 620 may be used to link to a record of metadata associated with each file. These files may be executable and dynamic link library (DLL) files. In certain cases, the metadata may be obtained using a versioninfo resource block embedded in each file. This may be obtained from a locally accessible exemplar computing device, e.g. as opposed to having each client computing device report this information over the network. Not all files necessarily contain such resource data, but a significant majority typically do. The metadata which can be obtained from this source may comprise one or more of an original file name, internal name, company name (e.g. publisher), file description, product name, file version, and product version associated with a given file. This metadata may be augmented with other information about the file, e.g. a file size and/or file name (including a path on the file system).
Returning to
In a first variation of
In a second variation of
In
The example of
When multiple differing sets of exemplar data signatures are used, a further state bitmap may be generated, at a client computing device, by comparing a set of generated data signatures with the second set of exemplar data signatures. These may be the same set of generated data signatures that are compared to the first set of exemplar data signatures (e.g. the generation may be performed once or periodically). Respective comparisons may thus be carried out between the data signatures generated at the computing device and the separately received first and second sets of exemplar data signatures 500, 540. The state bitmaps may thus further indicate a presence or absence of each file hash in the second set of exemplar file hashes.
Returning to
In one example, the second set of exemplar data signatures may be sent based on an earlier received set of state data. This state data may comprise one or more of received compressed state bitmaps and generated data signatures that are present on a client computing device 110 but are not present in the first set of exemplar data signatures. For example, a client computing device may be characterised based on a determined presence or absence of a set of files relating to the first set of exemplar data signatures, and this characterisation may be used to select one or more of a plurality of additional sets of exemplar data signatures. Alternatively, or additionally, this characterisation may be performed based on one or more received generated data signatures. In one case, non-matching generated data signatures may be transmitted one-by-one until these signatures are deemed (e.g. at the server computing device 120) to relate to a particular pre-stored set of exemplar data signatures, in which case the pre-stored set of exemplar data signatures are sent to the client computing device 110. This check may be based on a particular proportion of generated data signatures that match a pre-stored set. For example, a particular set of hundreds or thousands of exemplar data signatures may be characterised based on a received handful of generated data signatures; sending the additional set of exemplar data signatures may significantly reduce the amount of additional data that is to be transmitted across the network. In a case where 100 128-bit data signatures need to be transmitted and 50 of those data signatures are found within a exemplar set of 1000 data signatures, transmitting the data signatures as-is uses 1.6 Kbs (128*100 bits) but using the exemplar set even without compression uses under 1 Kb (128*50+1000 bits). This incremental approach may be repeated to reduce a number of generated data signatures that are to be transmitted from a client computing device 110 to the server computing device 120.
For example, in one case, state update data may be determined based on differences between the plurality of state bitmaps. For example, a first state bitmap may indicate that (a data signature corresponding to) a file is absent from the computing device 110 whereas a second state bitmap may indicate that the same (data signature corresponding to the) file is now present at the computing device 110, e.g. at a different time. Thus, the state update data may be determined based on this difference (or “delta”) between the first and second state bitmaps. If many of the files stay the same over time (e.g. between polling intervals), then the state update data may be of a reduced size compared to the second state bitmap.
In
On the server-side in this variation, the server computing device 120 receives (as part of step 713) the state update data from the client computing device 110 over the network in response to the further state request. As described, the state update data comprises differences between a plurality of state bitmaps generated at different times. The state update data is used by the server computing device 120 to update (step 714) the database 130 representing the state of the network. For example, where the state update data indicates that a file previously absent at a particular computing device 110 on the network is now present at the same computing device 110, the database 130 holding the file records for the computing devices 110 on the network can be updated to reflect the change.
In examples, a software update may be distributed to the endpoints on the network, which may be expected to perturb the state update reporting, e.g. since thousands of file changes may be detected at each endpoint. In such cases, a new set of exemplar data signatures can be created and distributed to the endpoints instead, with data signatures in the new set of exemplar data signatures corresponding to the software update. The increase in the network traffic in such cases may be a one-time burden comparable to a typical day of state update traffic.
Certain methods of determining a state of a computing device coupled to a network will now be described. The steps of such methods may correspond with the processes, routines etc. described herein with reference to the example network computing systems 100 and their components.
At block 801, the method comprises obtaining data signatures for a plurality of files that are stored on at least one volume of data storage accessible to the computing device. In certain cases, this may be performed in response to the receipt, at the computing device, of a request sent over the network to obtain a state of the computing device. In other cases, this may be performed as a periodic or continuous process on the computing device. Block 801 includes applying a hash function to binary data read from the plurality of files to generate the data signatures. In some examples, obtaining the data signatures includes parsing, at the computing device, a file-system data file to obtain data locations for the plurality of files. As described herein, the file-system data file may comprise a master file table (MFT) as used in NTFS, or a catalogue file in an APFS or HFS Plus file system. Other types of file-system data file, e.g. for different types of file system and/or OS, may be implemented in other examples.
The data locations for the plurality of files may be storage locations at which respective files of the plurality of files are stored in the at least one volume of data storage accessible by the computing device, for example. The hash function may thus be applied to binary data read from these data locations. For example, the hash function may be applied to bit values read from the data locations, or to bytes read therefrom in hexadecimal format. In certain examples, each of the plurality of files comprises executable code. For example, the plurality of files may comprise executable program files which have encoded instructions and can cause a computer to perform indicated tasks according to the encoded instructions when the file is executed on the computer. Example formats of such executable program files are described elsewhere in this detailed description.
At block 802, the method includes receiving, at the computing device over the network, a set of exemplar data signatures. As described herein, the set of exemplar data signatures may be a result of a scan of a particular computing device, taken to be an exemplar computing device. For example, the computing device may have a particular configuration, and thus have access to a preconfigured selection of files. Although block 802 is shown following block 801, in certain cases this may be reversed, e.g. block 801 may be triggered by the receipt of a set of exemplar data signatures in block 802.
At block 803, the method also involves generating, at the computing device, a state bitmap by comparing the generated data signatures with the set of exemplar data signatures. This may comprise generating data structures similar to those shown in
At block 804, the method also includes transmitting, from the computing device over the network, state data generated from the state bitmap. The state data may be transmitted in a file format over the network, e.g. as one or more files, for example. In other examples, the state data may be directly streamed over the network, e.g. in (compressed) network packets. In certain cases, the state data may be transmitted in a form similar to that shown in
In some examples, the method 800 also includes identifying, as a result of comparing the generated data signatures with the set of exemplar data signatures, one or more generated data signatures that are not present in the set of exemplar data signatures. For example, this may indicate that the computing device has access to one or more files, corresponding to the one or more generated data signatures, that are not accounted for in the set of exemplar data signatures. In such cases, additional state data, indicative of the said one or more generated data signatures absent in the set of exemplar data signatures, may be transmitted from the computing device over the network. In certain cases, this may be transmitted together with the state bitmap in the state data. The additional state data may be encoded and/or compressed as desired (although any reduction in size for compression of the additional state data will be limited, given the high entropy of this data).
In some examples, the set of exemplar data signatures comprises a first set of exemplar data signatures and the method 800 involves receiving, at the computing device over the network, a second set of exemplar data signatures. For example, the second set of exemplar data signatures may be associated with a different exemplar computing device, and/or a different configuration of the same exemplar computing device, compared to the first set of exemplar data signatures. A further state bitmap may be generated, at the computing device, by comparing the (previously) generated data signatures with the second set of exemplar data signatures. The computing device may then transmit, over the network, state data generated based on the further state bitmap. For example, the state data may be a compressed or otherwise processed version of the further state bitmap. In some cases, the second set of exemplar data signatures may be combined with the first set of exemplar data signatures to provide a superset of exemplar data signatures.
In some examples, the method 800 involves receiving, at the computing device over the network, a further state request. For example, the further state request may be received at the computing device separately to an earlier state request that precedes block 801. In response to the further state request, a plurality of state bitmaps generated at the computing device, in accordance with the separately received requests to obtain the state of the computing device, may be compared. State update data may be determined based on differences between the plurality of state bitmaps. The state update data may then be transmitted from the computing device over the network. As described herein, transmitting such difference data may reduce network traffic between the computing device and the server device compared to transmitting the state bitmaps, generated in response to the further state request, directly over the network.
At block 901, a set of exemplar data signatures, resulting from a scan of one or more exemplar computing devices, is obtained. In certain examples, this block may be performed following transmission of an (initial) state request to one or more computing devices over the network. Each data signature in the set of exemplar data signatures is generated by applying a hash function to binary data from a file in a set of files accessible to the one or more exemplar computing devices. For example, each data signature in the set of exemplar data signatures may represent a corresponding file that is accessible to the one or more exemplar computing devices.
At block 902, the set of exemplar data signatures is transmitted to the computing devices over the network. The set may be transmitted by the server computing device or the switch. In certain cases, the computing devices may access the exemplar data signatures from a network accessible storage location (e.g. using an API call). In certain cases, the set of exemplar data signatures may be distributed to the computing devices using peer-to-peer approaches, e.g. to distribute traffic more evenly over the network.
At block 903, state data is received from the computing devices over the network. For example, this may be received in response to a state request and/or in response to a computing device receiving the set of exemplar data signatures transmitted at block 902. The state data may be extracted from the payload of one or more data packets sent over the network and/or received as part of a data stream sent over a persistent data coupling created over the network. The state data may comprise compressed and/or encoded data that has been generated by the one or more client computing devices.
At block 904, the method 900 includes processing the state data to extract at least state bitmaps for the computing devices. The state bitmaps indicate a presence or absence of each data signature in the set of exemplar data signatures. For example, a given state bitmap returned from a given computing device may indicate which files are accessible to the given computing device versus the set of files, represented by the set of exemplar data structures, that are accessible to the one or more exemplar computing devices. The state bitmaps can thus be used to update a database representing the state of the network, which is shown at block 905. The database comprises data records indicating which files are present in each of the computing devices. The database may have a form similar to that described with respect to
In some examples, the set of exemplar data signatures may comprise a first set of exemplar data signatures associated with a first set of files, and the method 900 may involve obtaining a second set of exemplar data signatures associated with a second set of files. For example, the second set of files may correspond with another configuration of the one or more exemplar computing devices, as described. In such cases, the second set of exemplar data signatures may be transmitted to the computing devices over the network and the state bitmaps, extracted from the state data files received from the computing devices, further indicate a presence or absence of each data signature in the second set of exemplar data signatures.
In some examples, the method 900 includes receiving additional state data from one or more computing devices over the network, e.g. in response to a state request. The additional state data may be indicative of one or more data signatures which correspond, respectively, to one or more files present on the one or more computing devices that do not have a representative data signature in the set of exemplar data signatures. The additional state data may thus comprise residual data signatures, e.g. those data signatures in the generated set that are left over from the comparison made with the exemplar set. The additional state data, once received at the server device, can be used to update the database representing the state of the network. For example, the one or more files represented in the additional state data may be added to the database records with an indication of the one or more computing devices that have access to these files. For example, the generated data signatures from one or more computing devices may be added to the data signature records 620 as shown in
In some cases, additional state data is received from a plurality of computing devices and the method 900 includes determining, based on the received additional state data, that a file not having a representative data signature in the set of exemplar data signatures is present on a number of the plurality of computing devices, the number exceeding a predetermined threshold. For example, it may be determined that a particular file is accessible to multiple computing devices on the network but is not accounted for in the set of exemplar data signatures. If this is determined to be a large enough number of computing devices, e.g. larger than the predetermined threshold, the data signature representing the file may be added to the set of exemplar data signatures for subsequently transmitting to the computing devices over the network. This may occur for a plurality of files in some examples, and can allow for the set of exemplar data signatures to adapt over time to the network and which files are prevalent across the computing devices on the network and thus may be considered to be part of an exemplar, e.g. standard, configuration for a computing device on the network
In some examples, a further state request is transmitted to the computing devices over the network and state update data is received from the computing devices over the network in response to the further state request. The state update data comprises differences, e.g. deltas, between a plurality of state bitmaps generated at different times. For example, a first state bitmap generated at a given computing device based on a given set of exemplar data signatures can be compared to a second state bitmap generated at the same given computing device based on the same given set of exemplar data signatures, and the differences between the first and second state bitmaps can be transmitted as state update data. This transmitting of difference data rather than complete state data files can save network traffic between the computing devices and the server device. The state update data can be used in the same way to update the database representing the state of the network. For example, any differences encoded in the state update data can be applied to the database to update the databased based on the latest information on the state of the computing devices across the network.
In some cases, receiving state update data from the computing devices over the network comprises receiving subsets of the state update data at different times. For example, a first subset of the state update data, corresponding to a first subset of the computing devices, may be received at a first time. A second subset of the state update data, corresponding to a second subset of the computing devices, may then be received at a second time that is separated from the first time by a predefined time period. The predefined time period may be different to any network delay, e.g. queuing delay when network packets spend time in routing queues, transmission delay of the packets, or propagation delay of a signal over the network.
In some examples, the further state request includes a count request, e.g. a request for an indication of how many differences will be transmitted as part of the state update data. The method 900 may thus involve, before receiving the state update data, receiving count data from the computing devices over the network. The count data may indicate a number of differences to be sent in the state update data, e.g. corresponding to a number of data signatures that have changed in presence or absence at a given computing device on the network. For example, the count data may indicate how many differences are to be transmitted as part of the state update data. The method 900 may involve determining that the number of differences for one or more of the computing devices exceeds a predetermined threshold. In response to such a determination, the set of exemplar data signatures may be retransmitted to the said one or more of the computing devices. For example, a threshold of ten differences may be set such that, if it is determined that more than ten differences are to be transmitted as part of the state update data for a given computing device, the original set of exemplar data signatures may be retransmitted to the given computing device. In this way, if the previously transmitted set of exemplar data signatures becomes corrupted, lost, etc. then instead of reporting a high number of differences in the state update data each time (since the set of exemplar data signatures cannot be compared against) the set of exemplar data signatures is resent to the computing device(s) in question, so that comparison to the exemplar set can resume.
The example computing device 400 additionally implements a virtual computing device 416, e.g. acts as a host device. The virtual computing device 416 may be run on the memory 415 of the computing device 400. The virtual computing device 416 may use a virtual storage device 417, which may be a data volume that is stored as a virtual disk drive or disk image on the example computing device 400. The virtual computing device 416 and the virtual storage device 417 may be used to generate a set of exemplar data signatures. This is described with reference to
The method 1000 involves initiating, at block 1001, an installation of a predefined operating system on a virtual computing device 416. For example, this may comprise accessing an ISO file for the operating system, e.g. “inserting” a virtual optical disk. During the installation, it is determined whether a set of primary files for the operating system have been extracted at block 1002. For example, the primary files may relate to a set of core system files needed to boot the operating system within the virtual computing device and/or comprise a set of operating system files prior to configuration of a particular computing device (e.g. during later parts of an installation). The primary files may comprise a set of files that is larger in number than a set of files present when the installation completes, as, during configuration of the operating system, files that are deemed not to relate to a current configuration of the virtual computing device 416 may be deleted. In response to the extraction of the set of primary files, the installation is paused at block 1003. This may comprise pausing the operation of the virtual computing device 416 based on a trigger condition, such as a particular set of files or folder structure being present in a given location. In other cases, this may comprise not confirming a subsequent installation step (e.g. “clicking” on a “Continue with Installation” button). The installation may be paused at the point when it is determined that the primary files of the operating system have been extracted. At this point, the full file set for the operating system may be present in a pair of temporary directories which can be deleted at the conclusion of the installation. The contents of these files may be useful since otherwise, when the operating system is installed, many roles and features of the operating system may not be enabled, and the files associated with those roles and features may not be captured.
Following the pausing of the installation at block 1003, at block 1004, data stored on a virtual storage device 417 for the virtual computing device 415, e.g. within the memory 415 of the computing device 400, is copied to a prepared volume of data storage 430. For example, the prepared volume of data storage 430 may be a removable storage media, such as a USB drive, and/or an internal storage location of the computing device 400.
The set of exemplar data signatures is generated at block 1005 by parsing a file-system data file for the prepared volume of data storage 430 to obtain data locations for a plurality of files and applying a hash function to binary data read from the obtained data locations. For example, the data locations may comprise storage locations, within the prepared volume of data storage 430, at which the plurality of files are stored, e.g. with each storage location corresponding to a file of the plurality of files. Parsing the (file-system data file for the) prepared volume of data storage 430 may thus provide a set of exemplar data signatures for the full operating system build. For example, a scan from a Windows® 10 Enterprise installation may provide approximately 10,000 file hashes.
In some examples, the set of exemplar data signatures comprises a first set of exemplar data signatures, and the method 1000 involves generating a second set of exemplar data signatures. This may include scanning a computing device, having a predetermined configuration, to obtain a superset of data signatures for a plurality of files that are stored on at least one volume of data storage accessible by the computing device. For example, the predetermined configuration may correspond to the running of a specific version of an operating system, e.g. Windows® 10 build 1803. The computing device being scanned may be real or virtual, e.g. corresponding to the virtual computing device 416 run in memory 415. The method may also include removing data signatures which are present in the first set of exemplar data signatures from the superset of data signatures to obtain the second set of exemplar data signatures. For example, the superset of data signatures may comprise the union of the exemplar data signatures from the first and second sets of exemplar data signatures, which may each be resultant from a respective scan of a computing device. The data signatures in the superset which are already accounted for in the first set of exemplar data signatures can thus be removed to leave the second set of exemplar data signatures.
Certain examples described herein enable a state of a network to be efficiently determined. In certain cases, the state of the network may comprise an indication of a set of files accessible over the network, e.g. stored in relation to each device coupled to the network. These files may comprise executable code, e.g. that poses a certain security risk, and/or may comprise data files. The systems and methods described herein enable an inventory of these files to be efficiently generated at scale, e.g. even with hundreds of thousands of devices storing hundreds of thousands of files. An efficient inventory format is described in the form of a state database, which may be updated based on data exchanged over the network. The state database is efficiently constructed such that it is practically implementable within common storage sizes and may be accessed and updated rapidly. The data that is exchanged over the network is also optimised to reduce network traffic and distribution. Use of a highly compressible state bitmap format for the data exchange enables reporting to be limited to a few bytes or kilobytes of data for each network device. This may be further reduced in variations by making use of bitmap differences or deltas. The state bitmaps are generated based on exchanged sets of data signatures. These data signatures may be used to uniquely describe files while having a small fixed size, e.g. in relation to the file—typically a hundred bits or so. Data signatures may be grouped into sets based on different configurations to limit the number of “unmatched” data signatures that are transmitted from the client computing devices to a centralised server computing device. The methods and systems described herein may be implemented on large-scale enterprise networks with minimal disruption and so maybe distinguished from comparative approaches that quickly overload both the network bandwidth and inventory server resources. Certain examples therefore enable inventory at a scale that was not previously possible.
Examples as described herein may be implemented by a suite of computer programs which are run on one or more computing devices of the network. Software provides an efficient technical implementation that is easy to reconfigure; however, other implementations may comprise a hardware-only solution or a mixture of hardware devices and computer programs. One or more computer programs that are supplied to implement the embodiments described herein may be stored on one or more carriers, which may also be non-transitory. Examples of non-transitory carriers include a computer readable medium for example a hard disk, solid state main memory of a computer, an optical disc, a magneto-optical disk, a compact disc, a magnetic tape, electronic memory including Flash memory, ROM, RAM, a RAID or any other suitable computer readable storage device.
The above embodiments are to be understood as illustrative examples of the invention. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1908863 | Jun 2019 | GB | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 6847982 | Parker et al. | Jun 2005 | B2 |
| 7305383 | Kubesh | Dec 2007 | B1 |
| 7765410 | Costea | Jul 2010 | B2 |
| 8086627 | Pastorelli et al. | Dec 2011 | B2 |
| 8677480 | Yen | Mar 2014 | B2 |
| 9003476 | Baumhof | Apr 2015 | B2 |
| 9485145 | Bonczkowski et al. | Nov 2016 | B1 |
| 9629928 | Olsen | Apr 2017 | B1 |
| 9646284 | Lew et al. | May 2017 | B1 |
| 9690746 | Hosea et al. | Jun 2017 | B1 |
| 20050238011 | Panigrahy | Oct 2005 | A1 |
| 20050278395 | Sandaire | Dec 2005 | A1 |
| 20060195566 | Hurley | Aug 2006 | A1 |
| 20080049644 | Halbert | Feb 2008 | A1 |
| 20100122120 | Lin | May 2010 | A1 |
| 20120255017 | Sallam | Oct 2012 | A1 |
| 20140006796 | Smith | Jan 2014 | A1 |
| 20140317255 | Krishna | Oct 2014 | A1 |
| 20150150006 | Fitzgerald | May 2015 | A1 |
| 20200266996 | Carrott | Aug 2020 | A1 |
| Entry |
|---|
| Waltermire, David “Software Asset Managemnt, Continuous Monitoring” Sep. 16, 2015, V.2, Building Block. |
| Combined Search & Exam Report dated Dec. 4, 2019 for GB Application GB1908863.2. |
| Number | Date | Country | |
|---|---|---|---|
| 20200401695 A1 | Dec 2020 | US |
