Patent Application
20250047298
The present invention is in the field of computer data compression, and in particular the usage of data compression as a means for intrusion detection.
As computers become an ever-greater part of our lives, and especially in the past few years, data storage has become a limiting factor worldwide. Prior to about 2010, the growth of data storage far exceeded the growth in storage demand. In fact, it was commonly considered at that time that storage was not an issue, and perhaps never would be, again. In 2010, however, with the growth of social media, cloud data centers, high tech and biotech industries, global digital data storage accelerated exponentially, and demand hit the zettabyte (1 trillion gigabytes) level. Current estimates are that data storage demand will reach 175 zettabytes by 2025. By contrast, digital storage device manufacturers produced roughly 1 zettabyte of physical storage capacity globally in 2016. We are producing data at a much faster rate than we are producing the capacity to store it. In short, we are running out of room to store data, and need a breakthrough in data storage technology to keep up with demand.
The primary solutions available at the moment are the addition of additional physical storage capacity and data compression. As noted above, the addition of physical storage will not solve the problem, as storage demand has already outstripped global manufacturing capacity. Data compression is also not a solution. A rough average compression ratio for mixed data types is 2:1, representing a doubling of storage capacity. However, as the mix of global data storage trends toward multi-media data (audio, video, and images), the space savings yielded by compression either decreases substantially, as is the case with lossless compression which allows for retention of all original data in the set, or results in degradation of data, as is the case with lossy compression which selectively discards data in order to increase compression. Even assuming a doubling of storage capacity, data compression cannot solve the global data storage problem. The method disclosed herein, on the other hand, works the same way with any type of data.
Transmission bandwidth is also increasingly becoming a bottleneck. Large data sets require tremendous bandwidth, and we are transmitting more and more data every year between large data centers. On the small end of the scale, we are adding billions of low bandwidth devices to the global network, and data transmission limitations impose constraints on the development of networked computing applications, such as the “Internet of Things”.
Existing intrusion detection systems (“IDS”) operate on a basis that work by either looking for signatures of known attacks or deviations from normal activity. These deviations or anomalies are pushed up the stack and examined at the protocol and application layer. Limitations of the current IDS systems include the inability to process encrypted packets, Internet Protocol (“IP”) packets can still be faked, false positives are frequent, IDS are susceptible to protocol based attacks, and the signature library of standard IDS needs to be continually updated to detect the latest threats. An IDS is only as good as its signature library. If it isn't updated frequently, it won't register the latest attacks and it can't alert the user about them. Another issue is that existing systems are vulnerable until a new threat has been added to the signature library, so the latest attacks, and threats that are too new to have previously been observed, will always be a major concern. Moreover, even if a threat has been observed, the signature library must be kept up to date on a highly frequent basis, making user error and too-slow updates a continuous concern.
What is needed is a system and method for data compression with intrusion detection which overcomes the limitations of the existing art.
The inventor has developed a system and method for data compression with signature-based verifiable intrusion detection and prediction, that measures in real-time the probability distribution of an encoded data stream, compares the probability distribution to a reference probability distribution, and uses one or more statistical algorithms to determine the divergence between the two sets of probability distributions to determine if an unusual distribution is the result of a data intrusion. The system further comprises a signature generating component which correlates anomalous event data with known vulnerabilities and exploits to create a signature based on statistical information of the anomalous event. Computed statistics may be compared against a signature database to determine if a data intrusion has occurred.
According to a preferred embodiment, A system for data compression with signature-based verifiable intrusion detection and prediction, comprising one or more computers with executable instructions that, when executed: receive anomalous event data, the anomalous event data comprising one or more codewords; compare the anomalous event data to a database, the database comprising a plurality of signatures; when the comparison yields a match: generate an intrusion alert, the intrusion alert comprising the anomalous event data; and send the intrusion alert to a security monitoring system, is disclosed.
According to another preferred embodiment, A method for data compression with signature-based verifiable intrusion detection and prediction, comprising the steps of: receiving anomalous event data, the anomalous event data comprising one or more codewords; comparing the anomalous event data to a database, the database comprising a plurality of signatures; when the comparison yields a match: generating an intrusion alert, the intrusion alert comprising the anomalous event data; and sending the intrusion alert to a security monitoring system, is disclosed.
According to an aspect of an embodiment, intrusion alerts are validated by a machine learning system that notifies the security monitoring system when legitimate intrusions or false positive intrusions have been identified.
According to an aspect of an embodiment, the anomalous event data, the one or more codewords, and the plurality of signatures are processed through a predictive machine learning system that predicts whether an intrusion will be present based on the anomalous event data, the one or more codewords, and the plurality of signatures.
According to an aspect of an embodiment, one of either the anomalous event data, the one or more codewords, or the plurality of signatures are encrypted into secure representations of the same information.
The accompanying drawings illustrate several aspects and, together with the description, serve to explain the principles of the invention according to the aspects. It will be appreciated by one skilled in the art that the particular arrangements illustrated in the drawings are merely exemplary, and are not to be considered as limiting of the scope of the invention or the claims herein in any way.
encrypting data using split-stream processing.
The inventor has conceived, and reduced to practice, a system and method for data compression with signature-based verifiable intrusion detection and prediction, that measures in real-time the probability distribution of an encoded data stream, compares the probability distribution to a reference probability distribution, and uses one or more statistical algorithms to determine the divergence between the two sets of probability distributions to determine if an unusual distribution is the result of a data intrusion.
Perhaps strongest argument for the disclosed system and methods as a superior solution over the existing art may be its advantage with respect to signature libraries, which is an artifact of its fundamental difference in approach compared to traditional IDS. The scientific basis of compression-as-IDS does not rely on signatures, but on a statistical analysis of traffic payloads to detect divergence form an expected probability distribution; signatures are an irrelevant consideration. Threats are detected on the basis of deviation from a normal behavior dynamically, rather than seeking to match an observed behavior against a library of threat vectors as in the case of traditional IDS. In addition, employment of the dynamic codebook generator will ensure that compression ratios remain stable and measurable for purposes of intrusion detection in changing circumstances and in situations in which a codebook has been compromised. The system and methods benefit by having no dependence on any source of information other than the flow of data from the system in which it is installed.
In some embodiments, the data compression system may be configured to encode and decode genomic data. There are many applications in biology and genomics in which large amounts of DNA or RNA sequencing data must be searched to identify the presence of a pattern of nucleic acid sequences, or oligonucleotides. These applications include, but are not limited to, searching for genetic disorders or abnormalities, drug design, vaccine design, and primer design for Polymerase Chain Reaction (PCR) tests or sequencing reactions.
These applications are relevant across all species, humans, animals, bacteria, and viruses. All of these applications operate within large datasets; the human genome for example, is very large (3.2 billion base pairs). These studies are typically done across many samples, such that proper confidence can be achieved on the results of these studies. So, the problem is both wide and deep, and requires modern technologies beyond the capabilities of traditional or standard compression techniques. Current methods of compressing data are useful for storage, but the compressed data cannot be searched until it is decompressed, which poses a big challenge for any research with respect to time and resources.
The compression algorithms described herein not only compress data as well as, or better than, standard compression technologies, but more importantly, have major advantages that are key to much more efficient applications in genomics. First, some configurations of the systems and method described herein allow random access to compressed data without unpacking them first. The ability to access and search within compressed datasets is a major benefit and allows for utilization of data for searching and identifying sequence patterns without the time, expense, and computing resources required to unpack the data. Additionally, for some applications certain regions of the genomic data must be searched, and certain configurations of the systems and methods allow the search to be narrowed down even within compressed data. This provides an enormous opportunity for genomic researchers and makes mining genomics datasets much more practical and efficient.
In some embodiments, data compression may be combined with data serialization to maximize compression and data transfer with extremely low latency and no loss. For example, a wrapper or connector may be constructed using certain serialization protocols (e.g., BeBop, Google Protocol Buffers, MessagePack). The idea is to use known, deterministic file structure (schemes, grammars, etc.) to reduce data size first via token abbreviation and serialization, and then to use the data compression methods described herein to take advantage of stochastic/statistical structure by training it on the output of serialization. The encoding process can be summarized as: serialization-encode->compress-encode, and the decoding process would be the reverse: compress-decode->serialization-decode. The deterministic file structure could be automatically discovered or encoded by the user manually as a scheme/grammar. Another benefit of serialization in addition to those listed above is deeper obfuscation of data, further hardening the cryptographic benefits of encoding using codebooks.
In some embodiments, the data compression systems and methods described herein may be used as a form of encryption. As a codebook created on a particular data set is unique (or effectively unique) to that data set, compression of data using a particular codebook acts as a form of encryption as that particular codebook is required to unpack the data into the original data. As described previously, the compressed data contains none of the original data, just codeword references to the codebook with which it was compressed. This inherent encryption avoids entirely the multiple stages of encryption and decryption that occur in current computing systems, for example, data is encrypted using a first encryption algorithm (say, AES-256) when stored to disk at a source, decrypted using AES-256 when read from disk at the source, encrypted using TLS prior to transmission over a network, decrypted using TLS upon receipt at the destination, and re-encrypted using a possibly different algorithm (say, TwoFish) when stored to disk at the destination.
In some embodiments, an encoding/decoding system as described herein may be incorporated into computer monitors, televisions, and other displays, such that the information appearing on the display is encoded right up until the moment it is displayed on the screen. One application of this configuration is encoding/decoding of video data for computer gaming and other applications where low-latency video is required. This configuration would take advantage of the typically limited information used to describe scenery/imagery in low-latency video software applications, such an in gaming, AR/VR, avatar-based chat, etc. The encoding would benefit from there being a particularly small number of textures, emojis, AR/VR objects, orientations, etc., which can occur in the user interface (UI)—at any point along the rendering pipeline where this could be helpful.
In some embodiments, the data compression systems and methods described herein may be used to manage high volumes of data produced in robotics and industrial automation. Many AI based industrial automation and robotics applications collect a large amount of data from each machine, particularly from cameras or other sensors. Based upon the data collected, decisions are made as to whether the process is under control or the parts that have been manufactured are in spec. The process is very high speed, so the decisions are usually made locally at the machine based on an AI inference engine that has been previously trained. The collected data is sent back to a data center to be archived and for the AI model to be refined.
In many of these applications, the amount of data that is being created is extremely large. The high production rate of these machines means that most factory networks cannot transmit this data back to the data center in anything approaching real time. In fact, if these machines are operating close to 24 hours a day, 7 days a week, then the factory networks can never catch up and the entirety of the data cannot be sent. Companies either do data selection or use some type of compression requiring expensive processing power at each machine to reduce the amount of data that needs to be sent. However, this either loads down the processors of the machine, or requires the loss of certain data in order to reduce the required throughput.
The data encoding/decoding systems and methods described herein can be used in some configurations to solve this problem, as they represent a lightweight, low-latency, and lossless solution that significantly reduces the amount of data to be transmitted. Certain configurations of the system could be placed on each machine and at the server/data center, taking up minimal memory and processing power and allowing for all data to be transmitted back to the data center. This would enable audits whenever deeper analysis needs to be performed as, for example, when there is a quality problem. It also ensures that the data centers, where the AI models are trained and retrained, have access to all of the up-to-date data from all the machines.
One or more different aspects may be described in the present application. Further, for one or more of the aspects described herein, numerous alternative arrangements may be described; it should be appreciated that these are presented for illustrative purposes only and are not limiting of the aspects contained herein or the claims presented herein in any way. One or more of the arrangements may be widely applicable to numerous aspects, as may be readily apparent from the disclosure. In general, arrangements are described in sufficient detail to enable those skilled in the art to practice one or more of the aspects, and it should be appreciated that other arrangements may be utilized and that structural, logical, software, electrical and other changes may be made without departing from the scope of the particular aspects. Particular features of one or more of the aspects described herein may be described with reference to one or more particular aspects or figures that form a part of the present disclosure, and in which are shown, by way of illustration, specific arrangements of one or more of the aspects. It should be appreciated, however, that such features are not limited to usage in the one or more particular aspects or figures with reference to which they are described. The present disclosure is neither a literal description of all arrangements of one or more of the aspects nor a listing of features of one or more of the aspects that must be present in all arrangements.
Headings of sections provided in this patent application and the title of this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.
Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more communication means or intermediaries, logical or physical.
A description of an aspect with several components in communication with each other does not imply that all such components are required. To the contrary, a variety of optional components may be described to illustrate a wide variety of possible aspects and in order to more fully illustrate one or more aspects. Similarly, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may generally be configured to work in alternate orders, unless specifically stated to the contrary. In other words, any sequence or order of steps that may be described in this patent application does not, in and of itself, indicate a requirement that the steps be performed in that order. The steps of described processes may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to one or more of the aspects, and does not imply that the illustrated process is preferred. Also, steps are generally described once per aspect, but this does not mean they must occur once, or that they may only occur once each time a process, method, or algorithm is carried out or executed. Some steps may be omitted in some aspects or some occurrences, or some steps may be executed more than once in a given aspect or occurrence.
When a single device or article is described herein, it will be readily apparent that more than one device or article may be used in place of a single device or article. Similarly, where more than one device or article is described herein, it will be readily apparent that a single device or article may be used in place of the more than one device or article.
The functionality or the features of a device may be alternatively embodied by one or more other devices that are not explicitly described as having such functionality or features. Thus, other aspects need not include the device itself.
Techniques and mechanisms described or referenced herein will sometimes be described in singular form for clarity. However, it should be appreciated that particular aspects may include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. Process descriptions or blocks in figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of various aspects in which, for example, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those having ordinary skill in the art.
The term “bit” refers to the smallest unit of information that can be stored or transmitted. It is in the form of a binary digit (either 0 or 1). In terms of hardware, the bit is represented as an electrical signal that is either off (representing 0) or on (representing 1).
The term “byte” refers to a series of bits exactly eight bits in length.
The term “codebook” refers to a database containing sourceblocks each with a pattern of bits and reference code unique within that library. The terms “library” and “encoding/decoding library” are synonymous with the term codebook.
The terms “compression” and “deflation” as used herein mean the representation of data in a more compact form than the original dataset. Compression and/or deflation may be either “lossless”, in which the data can be reconstructed in its original form without any loss of the original data, or “lossy” in which the data can be reconstructed in its original form, but with some loss of the original data.
The terms “compression factor” and “deflation factor” as used herein mean the net reduction in size of the compressed data relative to the original data (e.g., if the new data is 70% of the size of the original, then the deflation/compression factor is 30% or 0.3.)
The terms “compression ratio” and “deflation ratio”, and as used herein all mean the size of the original data relative to the size of the compressed data (e.g., if the new data is 70% of the size of the original, then the deflation/compression ratio is 70% or 0.7.)
The term “data” means information in any computer-readable form.
The term “data set” refers to a grouping of data for a particular purpose. One example of a data set might be a word processing file containing text and formatting information.
The term “effective compression” or “effective compression ratio” refers to the additional amount data that can be stored using the method herein described versus conventional data storage methods. Although the method herein described is not data compression, per se, expressing the additional capacity in terms of compression is a useful comparison.
The term “sourcepacket” as used herein means a packet of data received for encoding or decoding. A sourcepacket may be a portion of a data set.
The term “sourceblock” as used herein means a defined number of bits or bytes used as the block size for encoding or decoding. A sourcepacket may be divisible into a number of sourceblocks. As one non-limiting example, a 1 megabyte sourcepacket of data may be encoded using 512 byte sourceblocks. The number of bits in a sourceblock may be dynamically optimized by the system during operation. In one aspect, a sourceblock may be of the same length as the block size used by a particular file system, typically 512 bytes or 4,096 bytes.
The term “codeword” refers to the reference code form in which data is stored or transmitted in an aspect of the system. A codeword consists of a reference code to a sourceblock in the library plus an indication of that sourceblock's location in a particular data set.
A stream analyzer 4701 receives an input data stream and analyzes it to determine the frequency of each unique data block within the stream. A bypass threshold may be used to determine whether the data stream deviates sufficiently from an idealized value (for example, in a hypothetical data stream with all-dyadic data block probabilities), and if this threshold is met the data stream may be sent directly to a data deconstruction engine 201 for deconstruction into codewords as described below in greater detail (with reference to
Stream conditioner 4702 receives a data stream from stream analyzer 4701 when the bypass threshold is not met, and handles the encryption process of swapping data blocks to arrive at a more-ideal data stream with a higher occurrence of dyadic probabilities; this facilitates both encryption of the data and greater compression efficiency by improving the performance of the Huffman coding employed by data deconstruction engine 201. To achieve this, each data block in the data stream is checked against a conditioning threshold using the algorithm |(P1−P2)|>TC, where P1 is the actual probability of the data block, P2 is the ideal probability of the block (generally, the nearest dyadic probability), and TC is the conditioning threshold value. If the threshold value is exceeded (that is, the data block's real probability is “too far” from the nearest ideal probability), a conditioning rule is applied to the data block. After conditioning, a logical XOR operation may be applied to the conditioned data block against the original data block, and the result (that is, the difference between the original and conditioned data) is appended to an error stream. The conditioned data stream (containing both conditioned and unconditioned blocks that did not meet the threshold) and the error stream are then sent to the data deconstruction engine 201 to be compressed, as described below in
To condition a data block, a variety of approaches may be used according to a particular setup or desired encryption goal. One such exemplary technique may be to selectively replace or “shuffle” data blocks based on their real probability as compared to an idealized probability: if the block occurs less-frequently than desired or anticipated, it may be added to a list of “swap blocks” and left in place in the data stream; if a data block occurs more frequently than desired, it is replaced with a random block from the swap block list. This increases the frequency of blocks that were originally “too low”, and decreases it for those that were originally “too high”, bringing the data stream closer in line with the idealized probability and thereby improving compression efficiency while simultaneously obfuscating the data. Another approach may be to simply replace too-frequent data blocks with any random data block from the original data stream, eliminating the need for a separate list of swap blocks, and leaving any too-low data blocks unmodified. This approach does not necessarily increase the probability of blocks that were originally too-low (apart from any that may be randomly selected to replace a block that was too-high), but it may improve system performance due to the elimination of the swap block list and associated operations.
It should be appreciated that both the bypass and conditioning thresholds used may vary, for example, one or both may be a manually-configured value set by a system operator, a stored value retrieved from a database as part of an initial configuration, or a value that may be adjusted on-the-fly as the system adjusts to operating conditions and live data.
System 1200 provides near-instantaneous source coding that is dictionary-based and learned in advance from sample training data, so that encoding and decoding may happen concurrently with data transmission. This results in computational latency that is near zero but the data size reduction is comparable to classical compression. For example, if N bits are to be transmitted from sender to receiver, the compression ratio of classical compression is C, the ratio between the deflation factor of system 1200 and that of multi-pass source coding is p, the classical compression encoding rate is RC bit/s and the decoding rate is RD bit/s, and the transmission speed is S bit/s, the compress-send-decompress time will be
while the transmit-while-coding time for system 1200 will be (assuming that encoding and decoding happen at least as quickly as network latency):
so that the total data transit time improvement factor is
which presents a savings whenever
This is a reasonable scenario given that typical values in real-world practice are C=0.32, RC=1.1·1012, RD=4.2·1012, S=1011, giving
such that system 1200 will outperform the total transit time of the best compression technology available as long as its deflation factor is no more than 5% worse than compression. Such customized dictionary-based encoding will also sometimes exceed the deflation ratio of classical compression, particularly when network speeds increase beyond 100 Gb/s.
The delay between data creation and its readiness for use at a receiving end will be equal to only the source word length 1 (typically 5-15 bytes), divided by the deflation factor C/p and the network speed S, i.e.
since encoding and decoding occur concurrently with data transmission. On the other hand, the latency associated with classical compression is
chosen above as well as N=512K, t=10, and p=1.05, this results in delayinvention ≈3.3·10−10 while delaypriorun ≈1.3·10−7, a more than 400-fold reduction in latency.
A key factor in the efficiency of Huffman coding used by system 1200 is that key-value pairs be chosen carefully to minimize expected coding length, so that the average deflation/compression ratio is minimized. It is possible to achieve the best possible expected code length among all instantaneous codes using Huffman codes if one has access to the exact probability distribution of source words of a given desired length from the random variable generating them. In practice this is impossible, as data is received in a wide variety of formats and the random processes underlying the source data are a mixture of human input, unpredictable (though in principle, deterministic) physical events, and noise. System 1200 addresses this by restriction of data types and density estimation; training data is provided that is representative of the type of data anticipated in “real-world” use of system 1200, which is then used to model the distribution of binary strings in the data in order to build a Huffman code word library 1200.
Since data drifts involve statistical change in the data, the best approach to detect drift is by monitoring the incoming data's statistical properties, the model's predictions, and their correlation with other factors. After statistical analysis engine 2920 calculates the probability distribution of the test dataset it may retrieve from monitor database 2930 the calculated and stored probability distribution of the current training dataset. It may then compare the two probability distributions of the two different datasets in order to verify if the difference in calculated distributions exceeds a predetermined difference threshold. If the difference in distributions does not exceed the difference threshold, that indicates the test dataset, and therefore the incoming data, has not experienced enough data drift to cause the encoding/decoding system performance to degrade significantly, which indicates that no updates are necessary to the existing codebooks. However, if the difference threshold has been surpassed, then the data drift is significant enough to cause the encoding/decoding system performance to degrade to the point where the existing models and accompanying codebooks need to be updated. According to an embodiment, an alert may be generated by statistical analysis engine 2920 if the difference threshold is surpassed or if otherwise unexpected behavior arises.
In the event that an update is required, the test dataset stored in the cache 2970 and its associated calculated probability distribution may be sent to monitor database 2930 for long term storage. This test dataset may be used as a new training dataset to retrain the encoding and decoding algorithms 2940 used to create new sourceblocks based upon the changed probability distribution. The new sourceblocks may be sent out to a library manager 2915 where the sourceblocks can be assigned new codewords. Each new sourceblock and its associated codeword may then be added to a new codebook and stored in a storage device. The new and updated codebook may then be sent back 2925 to codebook training module 2900 and received by a codebook update engine 2950. Codebook update engine 2950 may temporarily store the received updated codebook in the cache 2970 until other network devices and machines are ready, at which point codebook update engine 2950 will publish the updated codebooks 2945 to the necessary network devices.
A network device manager 2960 may also be present which may request and receive network device data 2935 from a plurality of network connected devices and machines. When the disclosed encoding system and codebook training system 2800 are deployed in a production environment, upstream process changes may lead to data drift, or other unexpected behavior. For example, a sensor being replaced that changes the units of measurement from inches to centimeters, data quality issues such as a broken sensor always reading 0, and covariate shift which occurs when there is a change in the distribution of input variables from the training set. These sorts of behavior and issues may be determined from the received device data 2935 in order to identify potential causes of system error that is not related to data drift and therefore does not require an updated codebook. This can save network resources from being unnecessarily used on training new algorithms as well as alert system users to malfunctions and unexpected behavior devices connected to their networks. Network device manager 2960 may also utilize device data 2935 to determine available network resources and device downtime or periods of time when device usage is at its lowest. Codebook update engine 2950 may request network and device availability data from network device manager 2960 in order to determine the most optimal time to transmit updated codebooks (i.e., trained libraries) to encoder and decoder devices and machines.
According to an embodiment, the list of codebooks used in encoding the data set may be consolidated to a single codebook which is provided to the combiner 3400 for output along with the encoded sourcepackets and codebook IDs. In this case, the single codebook will contain the data from, and codebook IDs of, each of the codebooks used to encode the data set. This may provide a reduction in data transfer time, although it is not required since each sourcepacket (or sourceblock) will contain a reference to a specific codebook ID which references a codebook that can be pulled from a database or be sent alongside the encoded data to a receiving device for the decoding process.
In some embodiments, each sourcepacket of a data set 3201 arriving at the encoder 3204 is encoded using a different sourceblock length. Changing the sourceblock length changes the encoding output of a given codebook. Two sourcepackets encoded with the same codebook but using different sourceblock lengths would produce different encoded outputs. Therefore, changing the sourceblock length of some or all sourcepackets in a data set 3201 provides additional security. Even if the codebook was known, the sourceblock length would have to be known or derived for each sourceblock in order to decode the data set 3201. Changing the sourceblock length may be used in conjunction with the use of multiple codebooks.
In this embodiment, for each bit location 3402 of the control byte 3401, a data bit or combinations of data bits 3403 provide information necessary for decoding of the sourcepacket associated with the control byte. Reading in reverse order of bit locations, the first bit N (location 7) indicates whether the entire control byte is used or not. If a single codebook is used to encode all sourcepackets in the data set, N is set to 0, and bits 3 to 0 of the control byte 3401 are ignored. However, where multiple codebooks are used, N is set to 1 and all 8 bits of the control byte 3401 are used. The next three bits RRR (locations 6 to 4) are a residual count of the number of bits that were not used in the last byte of the sourcepacket. Unused bits in the last byte of a sourcepacket can occur depending on the sourceblock size used to encode the sourcepacket. The next bit I (location 3) is used to identify the codebook used to encode the sourcepacket. If bit I is 0, the next three bits CCC (locations 2 to 0) provide the codebook ID used to encode the sourcepacket. The codebook ID may take the form of a codebook cache index, where the codebooks are stored in an enumerated cache. If bit I is 1, then the codebook is identified using a four-byte UUID that follows the control byte.
Here, a list of six codebooks is selected for shuffling, each identified by a number from 1 to 6 3501a. The list of codebooks is sent to a rotation or shuffling algorithm 3502, and reorganized according to the algorithm 3501b. The first six of a series of sourcepackets, each identified by a letter from A to E, 3503 is each encoded by one of the algorithms, in this case A is encoded by codebook 1, B is encoded by codebook 6, C is encoded by codebook 2, D is encoded by codebook 4, E is encoded by codebook 13 A is encoded by codebook 5. The encoded sourcepackets 3503 and their associated codebook identifiers 3501b are combined into a data structure 3504 in which each encoded sourcepacket is followed by the identifier of the codebook used to encode that particular sourcepacket.
According to an embodiment, the codebook rotation or shuffling algorithm 3502 may produce a random or pseudo-random selection of codebooks based on a function. Some non-limiting functions that may be used for shuffling include:
1. given a function f (n) which returns a codebook according to an input parameter n in the range 1 to N are, and given t the number of the current sourcepacket or sourceblock: f (t*M modulo p), where M is an arbitrary multiplying factor (1<=M<=p−1) which acts as a key, and p is a large prime number less than or equal to N;
2. f(A{circumflex over ( )}t modulo p), where A is a base relatively prime to p−1 which acts as a key, and p is a large prime number less than or equal to N;
3. f(floor (t*x) modulo N), and x is an irrational number chosen randomly to act as a key;
4. f(t XOR K) where the XOR is performed bit-wise on the binary representations of t and a key K with same number of bits in its representation of N. The function f (n) may return the nth codebook simply by referencing the nth element in a list of codebooks, or it could return the nth codebook given by a formula chosen by a user.
In one embodiment, prior to transmission, the endpoints (users or devices) of a transmission agree in advance about the rotation list or shuffling function to be used, along with any necessary input parameters such as a list order, function code, cryptographic key, or other indicator, depending on the requirements of the type of list or function being used. Once the rotation list or shuffling function is agreed, the endpoints can encode and decode transmissions from one another using the encodings set forth in the current codebook in the rotation or shuffle plus any necessary input parameters.
In some embodiments, the shuffling function may be restricted to permutations within a set of codewords of a given length.
Note that the rotation or shuffling algorithm is not limited to cycling through codebooks in a defined order. In some embodiments, the order may change in each round of encoding. In some embodiments, there may be no restrictions on repetition of the use of codebooks.
In some embodiments, codebooks may be chosen based on some combination of compression performance and rotation or shuffling. For example, codebook shuffling may be repeatedly applied to each sourcepacket until a codebook is found that meets a minimum level of compression for that sourcepacket. Thus, codebooks are chosen randomly or pseudo-randomly for each sourcepacket, but only those that produce encodings of the sourcepacket better than a threshold will be used.
The decoder 3750 receives the encoded data in the form of codewords, decodes it using the same codebook 3730 (which may be a different copy of the codebook in some configurations), but instead of outputting decoded data which is identical to the unencoded data received by the encoder 3740, the decoder maps and/or transforms the decoded data according to the mapping and transformation appendix, converting the decoded data into a transformed data output. As a simple example of the operation of this configuration, the unencoded data received by the encoder 3740 might be a list of geographical location names, and the decoded and transformed data output by the decoder based on the mapping and transformation appendix 3731 might be a list of GPS coordinates for those geographical location names.
In some embodiments, artificial intelligence or machine learning algorithms might be used to develop or generate the mapping and transformation rules. For example, the training data might be processed through a machine learning algorithm trained (on a different set of training data) to identify certain characteristics within the training data such as unusual numbers of repetitions of certain bit patterns, unusual amounts of gaps in the data (e.g., large numbers of zeros), or even unusual amounts of randomness, each of which might indicate a problem with the data such as missing or corrupted data, possible malware, possible encryption, etc. As the training data is processed, the mapping and transform appendix 3731 is generated by the machine learning algorithm based on the identified characteristics. In this example, the output of the decoder might be indications of the locations of possible malware in the decoded data or portions of the decoded data that are encrypted. In some embodiments, direct encryption (e.g., SSL) might be used to further protect the encoded data during transmission.
The encoder 3840 receives unencoded data, implements any behaviors required by the behavior appendix 3831 such as limit checking, network policies, data prioritization, permissions, etc., as encodes it into codewords using the codebook 3830. For example, as data is encoded, the encoder may check the behavior appendix for each sourceblock within the data to determine whether that sourceblock (or a combination of sourceblocks) violates any network rules. As a couple of non-limiting examples, certain sourceblocks may be identified, for example, as fingerprints for malware or viruses, and may be blocked from further encoding or transmission, or certain sourceblocks or combinations of sourceblocks may be restricted to encoding on some nodes of the network, but not others. The decoder works in a similar manner. The decoder 3850 receives encoded data, implements any behaviors required by the behavior appendix 3831 such as limit checking, network policies, data prioritization, permissions, etc., as decodes it into decoded data using the codebook 3830 resulting in data identical to the unencoded data received by the encoder 3840. For example, as data is decoded, the decoder may check the behavior appendix for each sourceblock within the data to determine whether that sourceblock (or a combination of sourceblocks) violates any network rules. As a couple of non-limiting examples, certain sourceblocks may be identified, for example, as fingerprints for malware or viruses, and may be blocked from further decoding or transmission, or certain sourceblocks or combinations of sourceblocks may be restricted to decoding on some nodes of the network, but not others.
In some embodiments, artificial intelligence or machine learning algorithms might be used to develop or generate the behavioral appendix 3831. For example, the training data might be processed through a machine learning algorithm trained (on a different set of training data) to identify certain characteristics within the training data such as unusual numbers of repetitions of certain bit patterns, unusual amounts of gaps in the data (e.g., large numbers of zeros), or even unusual amounts of randomness, each of which might indicate a problem with the data such as missing or corrupted data, possible malware, possible encryption, etc. As the training data is processed, the mapping and transform appendix 3831 is generated by the machine learning algorithm based on the identified characteristics. As a couple of non-limiting examples, the machine learning algorithm might generate a behavior appendix 3831 in which certain sourceblocks are identified, for example, as fingerprints for malware or viruses, and are blocked from further decoding or transmission, or in which certain sourceblocks or combinations of sourceblocks are restricted to decoding on some nodes of the network, but not others.
The decoder 3950 receives the encoded data in the form of codewords, decodes it using the same codebook 3930 (which may be a different copy of the codebook in some configurations), and but instead of outputting decoded data which is identical to the unencoded data received by the encoder 3940, the decoder converts the decoded data according to the protocol appendix, converting the decoded data into a protocol formatted data output. As a simple example of the operation of this configuration, the unencoded data received by the encoder 3940 might be a data to be transferred over a TCP/IP connection, and the decoded and transformed data output by the decoder based on the protocol appendix 3931 might be the data formatted according to the TCP/IP protocol.
In some embodiments, artificial intelligence or machine learning algorithms might be used to develop or generate the protocol policies. For example, the training data might be processed through a machine learning algorithm trained (on a different set of training data) to identify certain characteristics within the training data such as types of files or portions of data that are typically sent to a particular port on a particular node of a network, etc. As the training data is processed, the protocol appendix 3931 is generated by the machine learning algorithm based on the identified characteristics. In this example, the output of the decoder might be the unencoded data formatted according to the TCP/IP protocol in which the TCP/IP destination is changed based on the contents of the data or portions of the data (e.g., portions of data of one type are sent to one port on a node and portions of data of a different type are sent to a different port on the same node). In some embodiments, direct encryption (e.g., SSL) might be used to further protect the encoded data during transmission.
In this configuration, training data in the form of a set of operating system files 4110 is fed to a codebook generator 4120, which generates a codebook based on the operating system files 4110. The codebook may comprise a single codebook 4130 generated from all of the operating system files, or a set of smaller codebooks called codepackets 4131, each codepacket 4131 being generated from one of the operating system files, or a combination of both. The codebook 4130 and/or codepackets 4131 are sent to both an encoder 4141 and a decoder 4150 which may be on the same computer or on different computers, depending on the configuration. The encoder 4141 receives an operating system file 4110b from the set of operating system files 4110a-n used to generate the codebook 4130, encodes it into codewords using the codebook 4130 or one of the codepackets 4131, and sends encoded operating system file 4110b in the form of codewords to the decoder 4150. The decoder 4150 receives the encoded operating system file 4110b in the form of codewords, decodes it using the same codebook 4130 (which may be a different copy of the codebook in some configurations), and outputs a decoded operating system file 4110b which is identical to the unencoded operating system file 4110b received by the encoder 4141. Any codebook miss (a codeword that can't be found either in the codebook 4130 or the relevant codepacket 4131) that occurs during decoding indicates that the operating system file 4110b has been changed between encoding and decoding, thus providing the operating system file-based encoding/decoding with inherent protection against changes.
The combination of data compression with data serialization can be used to maximize compression and data transfer with extremely low latency and no loss. For example, a wrapper or connector may be constructed using certain serialization protocols (e.g., BeBop, Google Protocol Buffers, MessagePack). The idea is to use known, deterministic file structure (schemes, grammars, etc.) to reduce data size first via token abbreviation and serialization, and then to use the data compression methods described herein to take advantage of stochastic/statistical structure by training it on the output of serialization. The encoding process can be summarized as: serialization-encode->compress-encode, and the decoding process would be the reverse: compress-decode->serialization-decode. The deterministic file structure could be automatically discovered or encoded by the user manually as a scheme/grammar. Another benefit of serialization in addition to those listed above is deeper obfuscation of data, further hardening the cryptographic benefits of encoding using codebooks.
According to the embodiment, intrusion detection module 5160 may receive, retrieve, or otherwise obtain a codeword data stream, such as the data stream associated with codeword transmission 5140, and to perform analyses on the codeword data stream in order to determine if an unusual distribution of codewords has occurred (i.e., anomalous behavior), and if anomalous behavior is detected to categorize the behavior as data intrusion or from some other cause. In either case, the anomalous behavior may be recorded for further analysis and auditing, and an alert may be sent 5170 to user interface 5180 wherein a user can view and interact and configure system 5100 components. For compression to be used for the purpose of detecting intrusions, on-the-fly-builds of codebooks may be used to ensure that accurate, stable levels of compression can be measured for a specific device(s) on a specific platform. The codebook training module 5130 can enable a local device or server to build and provision new dynamic codebooks as needed on the basis of changing conditions, such as weather, changes to hardware or software, and other conditions.
Intrusion detection module 5160 is configured for unusual distribution detection (“UDD”) capability for the detection of a potential intrusion. Intrusion detection module 5160 can detect a UDD in a codeword data stream and identify a likely reason for a detected unusual compression ratio such as, for example, a source other than a likely intrusion such as a device error, a corrupted codebook, an environment change, or a likely intrusion. Because intrusion detection depends on highly localized monitoring of deviation from expected an expected compression ratio, dynamic codebooks provide a useful tool for intrusion detection for a few reasons. First, the codebook training module 5130 will enable fully automated local builds and provisioning of codebooks. This capability will enable new local deployments of the system 5100 for purposes of UDD quickly and with as little human intervention as possible. Codebook training module 5130 provides a practical approach to deploying the system for intrusion detection on a large scale with relative ease. Second, the dynamic codebooks will also enable local users operating hardware or software with communication capabilities to adapt the system for their use simply and easily. For example, a squadron of aircraft operating in an arctic environment may have different equipment than the same aircraft operating in a tropical environment, or the same equipment may generate data from certain equipment that is significantly different, such as ambient temperature. The same logic applies to situations in which changes in hardware, software, and environmental conditions have affected the content of machine files generated for transmission, automating the process of adapting to these changes.
Codebook training module 5130 provides a practical approach to both scale deployments of the system and to rapidly updating codebooks in existing system deployments, whether as a response to an intrusion or as an update in response to a reduction in compression ratio resulting from another source.
The user interface 5180 may be configured to display a variety of information related to, but not necessarily limited to, device and system compression levels, intrusion detection information and alerting, user selected risk sensitivity settings, controls related to the codebook training module 5130 (e.g., user selected threshold levels, test and training dataset size, etc.) and intrusion detection module 5160 (e.g., risk sensitivity threshold, divergence quantities, compression ratio limits, etc.), and/or the like.
According to the embodiment, statistical analysis engine 5220 is configured to use advanced statistical methods to establish whether a detected UDD is likely to be a result of an intrusion or some other cause. Statistical analysis engine 5220 may compute the probability distribution of the codeword data stream and compare that computed value to a reference probability distribution (i.e., a reference codebook) in order to calculate the divergence between the two sets of probability distributions, and use the calculated divergence to make a determination on whether an unusual distribution is due to an intrusion or some other cause. The reference codebook may be created by codebook training module 5130 and sent 5225 to intrusion detection module 5200 to be used for comparison tasks. Best-practice probability distribution algorithms such as Kullback-Leibler divergence, adaptive windowing, and Jensen-Shannon divergence may be used to compute the probability distribution of the received codeword data stream. In some implementations, the basis of intrusion detection module's 5200 analysis may be Kullback-Leibler divergence (also called KL divergence, or relative entropy), which is a type of statistical distance, to determine a measure of how an observed probability distribution P based on data generated in the “real-world” is different, or diverges in statistical terms, from a second reference probability distribution Q. In an embodiment, a large sample set of approximately independent and identically distributed (“iid”) symbols will act as sourceblocks to be used as a reference probability distribution “training” set to be used by codebook training module 5130 to build reference codebooks to be used as Q. The probability distribution of live data in a short window of time provides P. Data which precisely matches the training data distribution will have a KL-divergence of 0, which is observable at a compression ratio at or close to the expected ratio as measured during training. Data which deviates significantly from the training data distribution, i.e., an anomalous event, is observable as an unusual compression ratio, since this ratio is lower-bounded by and closely estimates the KL-divergence between P and Q. The compression/encoding techniques disclosed herein are highly stable and provide a highly stable data stream (of codewords) for monitoring. A UDD, consequently, can be detected casily and quicky. UDDs may include, but are not limited to: an out of tolerance compression ratio, such as 70% compression rising in some specified timeframe to 90%; out of tolerance compression ratio, low, such as 70% compression falling in some specified timeframe to 50%; and a suspiciously stable compression ratio over a selectable timeframe. The timeframe in these and other scenarios may be configured by a system user to suit their individual or enterprise goals. Likewise, a risk sensitivity threshold may be configured by a system user to suit their use cases and personal level of assumed risk.
KL-divergence is a well-established methodology for determining the expected excess surprise from using the probability Q, when the actual distribution is P. As implemented by the data compression and intrusion detection system 5100, the codebook generated by approximate iid sample data will be used as a model for Q, and for the live data the actual distribution is P, the codebook generated from the live data. A UDD event may be indicated when P exceeds the expected excess surprise. Although KL-divergence is a distance between two probability distributions, it is not a metric and is not symmetric in comparing probability distributions. This is a distinct difference of KL-divergence/relative entropy compared measurements of variation. It is a type of divergence, better characterized as a generalization of squared distance. It is a consequence of Shannon's Source Coding Theorem that the optimal coding (read: compression) rate of data is its entropy rate, and that this is achievable asymptotically. The design of the disclosed compression/encoding protocol ensures that the compression ratio indeed comes quite close to this theoretical limit when the data being encoded is identically distributed to the training data. A deeper consequence of the Source Coding Theorem is that, if an ideal entropy coding method, trained on data with distribution Q, is used to encode data that actually has probability distribution P, the degradation in compression will be the KL-divergence between P and Q. Therefore, the data whose probability distribution deviates from the training data will be compressed by the system 5100 at a rate exceeding the training data's entropy rate by the same amount.
Conversely, if data resembles the training data more so than would be expected for live data with all its natural variability, this is detectable as an unusually low compression ratio, because the actual compression rate will also have some natural level of variability resulting from transient deviations from the probability distribution of training data.
As a third tool for detecting anomalies, if data of any amount of deviation from training data in distribution shows an unusually stable compression ratio, this is a possible indicator of synthetic data being injected to obscure a possible intrusion/attack.
In various implementations, during codebook training and testing, statistical analysis engine 5220 can assess the expected compression ratio μ after verifying that sufficient data is available to obtain a reliable measurement, and also to estimate the variance σ in the compression ratio the system can expect to observe. During live data observation, statistical analysis engine 5220 can produce a data stream of current compression ratio, a temporally local measurement of the ratio between the bit rate of compressed data and the input raw data, using a windowed moving average, an Exponentially Weighted Moving Average (“EWMA”), or similar, according to various implementations. This numerical stream Xt will then be subtracted from u to obtain a current deviation from expected ratio, and the number of standard deviations from the mean,
fed to the alerting module 5240. In some implementations, as a default setting, it may be assumed that X, has a normal distribution, so that a system user can set a risk tolerance level for zt equal to 2Φ(−|Z|), where Φ is the standard normal cumulative distribution function. For example, a highly risk-averse user can ask for alerting if a null-hypothesis event occurs at or above a p-value of 5%, entailing a report when |zt|≥2. This quantity can easily be adjusted to accommodate multiple independent data feeds as well.
According to various embodiments, intrusion detection module 5200 can be configured to analytically compute the probability distribution of this quantity zt under the assumption that the input data is a true iid symbol stream. Then, using the resulting parametrized family of distributions {fθ: θ∈Ω}, not only will σ be calculated during the training and testing phase, but an empirical distribution function of z will be computed, and from it, the most likely parameter choice θ and corresponding distribution fθ will be learned. This can enable the system to estimate the probability p that an observed deviation from the mean would be observed under null-hypothesis conditions (i.e., no intrusion or unusual state), which will trigger an alert when p exceeds a user-determined risk tolerance threshold. Since this method eschews the assumption of normality in the time series Xt, it can provide an even more accurate and sensitive UDD mechanism.
When Xt exceeds the threshold in the positive direction, alerting module 5240 can generate an alert to the effect that an unusual data distribution has been observed can be recorded/transmitted, indicating a possible intrusion or interruption. Anomalous event data may be stored in an event database 5230, the anomalous event data comprising the computed divergence, the computed probability distribution, and the codeword. Alerting module 5240 is further configured to send the generated alerts to a user interface 5215 as well as other information and statistics about the codeword data stream and the probability distribution and compression ratios for devices and systems, and/or the like. When X, falls below the threshold (i.e., z, is sufficiently negative), an alert is generated to the effect that a possible “replay attack” is observed, wherein training data is injected into the system whose output data is being compressed instead of the expected real data feed. Furthermore, the variance in X, will also be monitored in a recent temporal window, and excessive stability or volatility will be reported as these can also indicate possible attacks with synthetic data injection.
Gaining access to a network via intrusion, once achieved by an attacker, provides access to an entire system, or at least a large part of a system. An attacker who has achieved access to a codebook by whatever means, however, only has access to information encoded by that codebook. With access to a single codebook, the attacker has no access to information that was encoded by other codebooks. Consequently, the attacker could not, without access to additional codebooks, conduct an attack via any other codebook. Moreover, if malware is encoded in a transmission by a codebook and is detected by the system, and transmissions encoded by that codebook are terminated, the attacker will lose their access immediately to that codebook data stream and will not force the entire data stream encoded by any other codebooks to be terminated. Consequently, disruption based on an intrusion detected by data compression with intrusion detection system will be limited only to the data encoded by the compromised codebook. Finally, upon determination of an intrusion UDD, the compromised codebook can be replaced within minutes by codebook training module 5130 and transmissions resumed.
Key to determining whether an intrusion has occurred, once a UDD has been observed, will be to determine if the UDD was likely an intrusion or the result of some other event. Other potential causes of a UDD include the following: a device error or corrupted codebook, including zero data; a change in environment; and an intrusion/hack.
With respect to a device error, if a UDD is detected, and encoded data is decoded and found to be unreadable, the likely causes are device error or a corrupted codebook. For devices using multiple codebooks, if significant variance of a similar character is simultaneously detected in multiple codebooks in use by that system, the likely cause is a device error. Individual circumstances need to be taken in account, however, since a single gateway may encode data from many sources on a platform, for example, and while one system, such as pressure monitoring, may be faulty and cause a UDD to occur even if other systems are functioning normally. Consequently, in an operational environment, correlation with other systems, such as a fault detection system, may be integrated as a part of an implementation of an intrusion detection system.
With respect to a change in environment, if other devices on the same platform are monitoring a similar event, such as outside air temperature, and several record a UDD simultaneously, a change in environment is a likely cause. Again, correlation with a real-world change seen in the data, such as the temperature readings on multiple devices or systems, could help avoid a false positive for a potential intrusion.
With respect to an intrusion/hack, when using the compression/encoding methods described herein variance tends to be very small, typically in the range of +/−2-3% for most data streams. Significant variance in timeframes of more than a few seconds, or more than one or two encoded messages, is rare, unless there is a major change in device hardware or software. Consequently, if device error/corrupted codebook/environmental change can be eliminated as a cause, an intrusion is a likely source of a UDD.
According to the embodiment, a signature correlation engine 5460 is present and configured to create and maintain a signature database 5470 of predefined signatures associated with known malicious behavior (e.g., known threat actors and known cyber vulnerabilities, exploits, malware, etc.). The database may contain information related to specific patterns, characteristics, or signatures associated with known threats, attacks, or vulnerabilities. These signatures are, generally, derived from analysis of historical attack data and the behavior of known malware. Signatures may be expressed in the form of regular expressions or specific byte sequences. Regular expressions are powerful patterns that allow for flexible matching of complex data structures.
According to the embodiment, statistical analysis engine 5420 is configured to use advanced statistical methods to establish whether a detected UDD is likely to be a result of an intrusion or some other cause. Statistical analysis engine 5420 may compute the probability distribution of the codeword data stream and compare that computed value to a reference probability distribution (i.e., a reference codebook) in order to calculate the divergence between the two sets of probability distributions, and use the calculated divergence to make a determination on whether an unusual distribution is due to an intrusion or some other cause. The reference codebook may be created by codebook training module 5130 and sent 5425 to intrusion detection module 5400 to be used for comparison tasks.
During live data observation, statistical analysis engine 5420 can produce a data stream of current compression ratio, a temporally local measurement of the ratio between the bit rate of compressed data and the input raw data, using a windowed moving average, an Exponentially Weighted Moving Average (“EWMA”), or similar, according to various implementations.
When X, exceeds the threshold in the positive direction, alerting module 5440 can generate an alert to the effect that an unusual data distribution has been observed can be recorded/transmitted, indicating a possible intrusion or interruption. Anomalous event data may be stored in an event database 5430, the anomalous event data comprising the computed divergence, the computed probability distribution, and the codeword. The anomalous event data stored in event database 5430 may be referred to as historical event data and used for signature generation, according to an embodiment. Alerting module 5240 is further configured to send the generated alerts to a user interface 5415 as well as other information and statistics about the codeword data stream and the probability distribution and compression ratios for devices and systems, and/or the like. When X, falls below the threshold (i.e., z, is sufficiently negative), an alert is generated to the effect that a possible “replay attack” is observed, wherein training data is injected into the system whose output data is being compressed instead of the expected real data feed. Furthermore, the variance in X, will also be monitored in a recent temporal window, and excessive stability or volatility will be reported as these can also indicate possible attacks with synthetic data injection.
According to the embodiment, signature correlation engine 5460 is configured to obtain a computed divergence of a codeword data stream associated with an anomalous event as well as other information and statistics about the codeword data stream and the probability distribution and compression ratios for devices and systems, and/or the like, and use this information to generate a signature of a malicious entity associated with the anomalous event. Signature correlation engine 5460 may obtain anomalous event data from event database 5430. In some embodiments, the signatures generated by signature correlation engine 5430 may be based on, at least in part, on a computed divergence associated with an anomalous event. For example, signature correlation engine 5460 can obtain historical anomalous event data from event database 5430, the historical anomalous event data may comprise historical divergence computations and historical probability distributions associated with an anomalous event as detected by intrusion detection module 5400, and use this information to generate a signature with a known vulnerability, exploit, and/or malicious actor based on correlated patterns of behavior. Furthermore, correlation engine 5460 may also receive external information about known threats actors, vulnerabilities, malware, etc., and correlate the anomalous event data with the external information to generate signatures. The result is signature database 5470 comprising signatures which identify known malicious actors based on a various statistical attributes such as, for example, a computed divergence and other statistics about the codeword data stream and the probability distribution. According to an aspect of an embodiment, the event data and statistics used to generate a signature can include a data stream of current compression ratio and/or a temporally local measurement of the ratio between the bit rate of compressed data and the input raw data.
According to various embodiments, signature correlation engine 5460 is configured to generate a signature based at least in part on various external data obtained from a plurality of sources. The external data can include information related to known malicious actors or entities. Such information may be received from a one or more cybersecurity/network/security/etc. monitoring systems which may be integrated with one or more systems, components, or processes described herein. For example, security information and event management systems may provide information about potential security threats and vulnerabilities. Another source of external data which may be obtained include threat intelligence feeds. These feeds are databases or lists of known malicious entities, IP addresses, domains, hashes, and other indicators. Other exemplary sources of external data include, but are not limited to, open source intelligence, information sharing and analysis centers, and commercial threat intelligence providers.
According to an implementation, statistical analysis engine 5420 may compute a divergence between a first computed probability distribution and a reference probability distribution, compare the computed divergence to a predetermined threshold, and generate an intrusion alert comprising anomalous event data based on the comparison. Statistical analysis engine 5420 can send the computed divergence of a codeword data stream associated with an anomalous event as well as other information and statistics about the codeword data stream and the probability distribution and compression ratios for devices and systems, and/or the like to the signature correlation engine 5460. The signature correlation engine 5460 may compare the received anomalous event data, the computed divergence, the probability distribution, and any other available statistics to signatures stored in signature database 5470 to identify a match. When a match is found between the observed patterns and a signature in the database, the alerting module 5440 generates an alert about the presence of a possible threat. The alert may be sent to a security monitoring system and may serve as a trigger for further investigation by security personnel.
According to an embodiment, if a match is not found, the obtained event data and statistics may be used to generate a new signature associated with the anomalous event. In this way, new threats may be added to the signature database when they are detected by intrusion detection module 5400.
According to an embodiment, additional information about the signature, such as the type of attack, the associated vulnerabilities, and other contextual details may be included in the signature as metadata. In an embodiment, the signature can include a compression, ration, a divergence, one or more codewords, and a probability distribution.
It's important to note that the exact structure and format of the stored signatures can vary between different intrusion detection module implementations and security platforms. The goal is to create signatures that are specific enough to identify malicious activities accurately while minimizing the likelihood of false positives. Additionally, signature database 5470 is regularly updated to include new signatures and improve detection capabilities in response to emerging threats.
In some implementations, platform 5700 may be implemented as a cloud-based service or system which hosts and/or supports various microservices or subsystems (e.g., components 5710-5770 implemented as microservices/subsystems). In some implementations, platform 5700 may be implemented as computing device comprising a memory and a processor, with computer readable programming instructions (or other computer-readable storage media) stored within the memory and operable/executable by/on the processor which cause the computing device to perform various operations associated with the execution of one or more platform tasks described herein.
According to the embodiment, stream analyzer 5710 is present and configured to analyze an input data stream to determine it statistical properties. This may comprise performing frequency analysis on data blocks within the input stream. It can determine the most frequent bytes or strings of bytes that occur at the beginning of each data block and designates these as prefixes. It may compile a prefix table based on the frequency distribution.
According to the embodiment, data transformer 5720 is present and configured to apply one or more transformations to the data to make it more compressible and secure. In an implementation, the platform applies the Burrows-Wheeler Transform (BWT) to the prefixes in the prefix table. This transformation makes the data more compressible while also providing a layer of encryption.
According to the embodiment, stream conditioner 5730 is present and configured to produce a conditioned data stream and an error stream. For example, for each data block, it compares the block's real frequency against an ideal frequency. If the difference exceeds a threshold, it applies a conditioning rule. It then applies a logical XOR operation and append the output to an error stream.
The dyadic distribution module 5740 receives the data stream and implements the core algorithm. This may comprise transforming the input data into a dyadic distribution whose Huffman encoding is close to uniform. It stores the transformations in a compressed secondary stream which may be (selectively) interwoven with the first, currently processing input stream.
Dyadic distribution module 5740 may integrate with transformation matrix generator 5745. The transformation matrix generator creates and manages the transformation matrix B.
According to an aspect, the generator constructs a nonnegative, row-stochastic matrix where each entry represents the probability of transforming one state to another as an instance of matrix B. The matrix is configured to ensure that the transformation reshapes the data distribution while introducing controlled randomness.
According to an implementation, transformation matrix generator 5745 creates the transformation matrix B based on the initial analysis of the input data distribution provided by the stream analyzer. This matrix B is a component that dyadic distribution module 5740 will use throughout the process. As the dyadic distribution module receives each data block, it consults the transformation matrix B to determine how to transform the data. For each state (or symbol) in the input data, the data transformer uses the corresponding row in matrix B to determine the probability distribution for transforming that state to other states. The dyadic distribution module may use a random number generator (such as provided by security module 5770) to select a transformation based on the probabilities in matrix B. This introduces controlled randomness into the process.
Through these transformations, the dyadic distribution module reshapes the data distribution to approach the dyadic distribution implied by the Huffman coding (as determined by the Huffman encoder/decoder). As transformations are applied, dyadic distribution module 5740 provides feedback to transformation matrix generator 5745 about the actual transformations performed. This allows the transformation matrix generator to refine matrix B if necessary. According to an embodiment, if the input data distribution changes over time, the transformation matrix generator can adapt matrix B based on new information from the stream analyzer. The dyadic distribution module will then use this updated matrix for subsequent transformations. The dyadic distribution module keeps track of the transformations it applies and generates a secondary data stream containing this information. This “transformation data” is important for the decoding process and may be interleaved with the main data stream by interleaver 5760. The transformation matrix generator continually works to optimize matrix B to minimize the amount of transformation data needed while maintaining the desired dyadic distribution.
Both transformation components (dyadic distribution module and matrix generator) work together to ensure that the transformations contribute to the cryptographic security of the system. The transformation matrix generator designs matrix B to make prediction of future states difficult, while the dyadic distribution module applies these transformations in a way that passes the modified next-bit test. In essence, the dyadic distribution module and transformation matrix generator form a tight feedback loop. The transformation matrix generator provides the rules for transformation (in the form of matrix B), while the dyadic distribution module applies these rules to the actual data. The results of these transformations then inform potential updates to the transformation rules, allowing the system to maintain optimal compression and security as it processes the data stream. This close interaction allows the system to dynamically balance compression efficiency and cryptographic security, adapting to changes in the input data characteristics while maintaining the core properties that make the dyadic distribution algorithm effective.
The input data then flows into a Huffman encoder/decoder 5750 which is configured to perform Huffman coding for compression and decoding for decompression. This may comprise constructing a Huffman tree based on the probability distribution of the input data, and assigning shorter codewords to more frequent symbols for compression. For decompression, it reverses the process.
According to the embodiment, interleaver 5760 is present and configured to interleave the compressed and encrypted data streams. This may comprise combining the main data stream (e.g., the input data stream that has been processed by one or more platform components) with the secondary “transformation data” stream according to a specific partitioning scheme to create the final output. This scheme is designed to maximize security while maintaining efficient compression. Interleaver 5760 may integrate with security module 5770 during data processing. In an embodiment, security module implements security features such as the modified next-bit test. For example, the interleaver works with the security module to determine how many bits from each stream should be included in each block of the output. This allocation may be dynamic and based on security requirements and the current state of the data. In some implementations, before interleaving, the security module encrypts the transformation data using a cryptographic algorithm. This adds an extra layer of security to the sensitive information about how the data was transformed. In some implementations, the security module provides cryptographically secure random numbers to the interleaver (or other platform components such as dyadic distribution module). These may be used to introduce controlled randomness into the interleaving process, making it harder for an adversary to separate the two streams.
As the interleaver combines the streams, the security module performs ongoing checks to ensure the resulting stream maintains the required cryptographic properties, such as passing the modified next-bit test. According to an aspect, security module 5770 monitors the entropy of the interleaved stream. If the entropy drops below a certain threshold, it signals the interleaver to adjust its strategy, possibly by including more bits from the transformation data stream. In embodiments where the system uses cryptographic keys (e.g., for encrypting the transformation data), the security module manages these keys and provides them to the interleaver as needed. According to an aspect, based on feedback from the security module about the cryptographic strength of recent output, interleaver 5760 may adaptively change its interleaving strategy.
In an implementation, the security module advises the interleaver on how to maintain consistent timing in its operations to prevent timing-based attacks. This might involve adding deliberate delays or dummy operations. The interleaver may consult the security module on how to securely include any necessary headers or metadata in the output stream. This ensures that even auxiliary data doesn't compromise the system's security. According to an aspect, security module 5770 provides integrity check values (e.g., hash values or MAC codes) to interleaver 5760, which are then incorporated into the output stream. These allow the receiver to verify the integrity of the received data. According to another aspect, security module 5770 guides the interleaver in implementing techniques to resist side-channel attacks, such as ensuring that the power consumption or electromagnetic emissions during interleaving don't leak information about the data being processed.
In an implementation, if the interleaver encounters any issues during the interleaving process, it may consult the security module on how to handle these errors securely without leaking information about the underlying data or transformation process. In an implementation, the interleaver, guided by the security module, can include secure hints or markers in the output stream that will assist in the decoding process without compromising security. The interleaver and security module work in tandem to produce an output stream that is both compressed and securely encrypted. The interleaver focuses on efficiently combining the data streams, while the security module ensures that every step of this process maintains the cryptographic properties of the system. This close cooperation allows the platform to achieve its dual goals of data compression and encryption in a single, efficient process.
According to an embodiment, the platform may be modified to only send the modified stream without the secondary stream containing the modification information. This alteration fundamentally changes the nature of the compression from lossless to lossy, while simultaneously strengthening the encryption aspect of the system. The dyadic distribution module, guided by transformation matrix generator 5740, would still modify the input data to achieve a dyadic distribution. However, without the accompanying transformation data stream, perfect reconstruction of the original data becomes impossible, even with possession of the codebook used by Huffman encoder/decoder 5750.
Interleaver 5820 may receive from mode selector 5810 a signal and/or instruction (illustrated as the dotted line) on what process to apply to the one or more input data streams. If the platform is configured to perform the original lossless mode, interleaver 5820 interleaves the compressed input data stream and the secondary transformation data stream. If the platform is configured to perform lossy compression, interleaver 5820 does not interleave the two data streams, but instead transmits only the compressed input data stream. If the platform is configured to perform a modified lossless compression, interleaver 5820 can transmit the compressed input data stream by itself in a first transmission session, and then it may transmit the secondary transformation data stream by itself in a second transmission session. In some embodiments, the secondary transformation data stream may be encrypted according to a suitable data encryption technique prior to transmission. Encryption techniques that may be implemented can include, but are not limited to, advance encryption standard (AES), asymmetric encryption (e.g., RSA), symmetric encryption (e.g., Twofish), and/or the like.
Security module's 5840 role becomes even more critical in the implementation of lossy modified system. It ensures that the encrypted data stream maintains its cryptographic strength, potentially approaching perfect encryption. The absence of the secondary stream eliminates a potential attack vector, as the transformation information is never transmitted. Interleaver's 5820 function would be simplified, focusing solely on managing the primary data stream, but it would still work closely with the security module to maintain the stream's cryptographic properties.
This approach presents a compelling trade-off between data integrity and transmission efficiency coupled with enhanced security. The stream analyzer's role remains the same in analyzing the input data characteristics, allowing the platform to optimize the compression and transformation processes. The loss of data introduced by this method is directly related to the transformations applied by the data transformer, guided by the transformation matrix generator.
Potential applications for this modified system include scenarios where perfect data reconstruction is not critical, but high compression ratios and stringent security requirements are paramount. Examples may include certain types of media streaming, sensor data transmission in IoT environments, or secure transmission of non-critical telemetry data.
According to an embodiment, to address concerns about data integrity, platform 5800 may incorporate a configurable loss threshold 5841 managed by security module 5840. This threshold can allow users to set a maximum acceptable level of data loss. If the estimated loss exceeds this threshold, the platform could automatically revert to the lossless mode or alert the user.
Additionally, the platform may be extended to include a data quality estimator component 5830. This component may work in conjunction with various components (e.g., stream analyzer, data transformer, dyadic distribution module) to provide real-time estimates of the quality of the compressed and encrypted data compared to the original. This could be particularly useful in applications like media streaming, where maintaining a certain level of perceptual quality is crucial.
Finally, it's worth noting that the lossy, high-security mode could potentially offer resistance to certain types of side-channel attacks, as the lack of perfect reconstruction could mask some of the subtle correlations that these attacks often exploit. In an embodiment, security module 5840 can be expanded to include specific protections 5842 against such attacks, further enhancing the overall security profile of the system. These protections would aim to mitigate various types of side-channel vulnerabilities that could potentially leak information about the encryption process or the data being processed. For example, some specific protections that may be implemented can include, but are not limited to, timing attack mitigation, power analysis countermeasures, electromagnetic emission protection, cache attack prevention, branch prediction attack mitigation, fault injection resistance, memory access patter obfuscation, randomization techniques, microarchitectural attack mitigations, side-channel resistant algorithms, runtime monitoring, and adaptive countermeasures.
Prediction and validation subsystem 6320 enhances the intrusion detection module's capabilities. It receives various types of data from multiple sources within the system to perform its functions. Input data for the prediction and validation subsystem may include but is not limited to real-time codeword streams from codeword collector 5410, historical event data from event database 5430, signature information from the signature database 5470, and statistical analysis results from statistical analysis engine 5420. Prediction and validation subsystem 6320 processes diverse data to predict potential intrusions and validate identified anomalies. For prediction, it analyzes patterns in the real-time data stream, comparing them against historical patterns associated with known intrusions. It also considers the frequency and distribution of codewords, looking for deviations that might indicate an emerging threat. For validation, the subsystem examines detected anomalies in more detail, correlating them with known signatures and historical events to determine the likelihood of a true intrusion. This process helps reduce false positives by distinguishing between genuine threats and benign anomalies.
Various machine learning networks could be employed within this subsystem, each offering unique advantages. Recurrent Neural Networks (RNNs) or Long Short-Term Memory (LSTM) networks are well-suited for analyzing sequential data, making them ideal for processing time-series data like codeword streams. They could be used to identify temporal patterns indicative of intrusions. Convolutional Neural Networks (CNNs), while typically used for image processing, can be adapted for intrusion detection by treating data streams as 1D images. They excel at identifying spatial patterns, which could be useful for detecting certain types of attacks. Random Forests or Gradient Boosting Machines are effective for classification tasks and can handle a mix of categorical and numerical data. They could be used to classify events as intrusions or non-intrusions based on multiple features. Autoencoders can be used for anomaly detection by learning to reconstruct normal system behavior and flagging significant deviations as potential intrusions.
Prediction and validation subsystem may output validated events 6330 and a false positive event log 6340. Validated events 6330 store confirmed intrusions, including details about the nature of the intrusion, the data patterns that led to its detection, and the confidence level of the prediction. False positive event log 6340 stores instances where the system initially flagged an event as an intrusion, but further analysis determined it was not a threat. This information aids in refining the system's accuracy over time. Results from Prediction and validation subsystem may also sent to alerting module 5440. This allows users to interact with the results through a user interface, viewing detailed information about predicted and validated intrusions, as well as any false positives that were identified. Users can review these results, provide feedback, and even adjust system sensitivity based on the accuracy of the predictions and validations. The continuous feedback loop created by user interactions, along with the ongoing analysis of validated events and false positives, allows a machine learning training subsystem 6310 to continuously refine and improve the models used in the prediction and validation process. This ensures that the system becomes more accurate and effective over time, adapting to new types of threats and changing network behaviors.
Machine learning training subsystem 6310 is responsible for continuously improving the prediction and validation capabilities of the system. It utilizes historical data from event database 5430 and real-time data from codeword collector 5410 to train and refine the machine learning models used by prediction and validation subsystem 6320. This ongoing training process allows the system to adapt to new types of threats and evolving attack patterns.
In one embodiment, an encryption module 5500 adds an extra layer of security to the entire intrusion detection process. It works with all other components of the system to encrypt sensitive data, including codewords, signatures, and event logs. This ensures that even if an attacker manages to intercept data within the system, they would not be able to easily decipher its contents. Encryption module 5500 leverages the dyadic distribution-based compression and encryption techniques described in
The encryption process begins when encryption module 5500 receives data from various components of the intrusion detection system. This data may include but is not limited to codewords from codeword collector 5410, historical event data from event database 5430, signatures from signature database 5470, and alerts generated by alerting module 5440. The encryption module first analyzes the input data to determine its characteristics and sensitivity level.
Using the dyadic distribution algorithm, the encryption module transforms the input data into a format that approaches a dyadic distribution. This process involves creating a transformation matrix and using it to determine the probability distribution for transforming each state in the input data to other states. A secure random number generator is then employed to select transformations based on the probabilities in the transformation matrix. This step not only compresses the data but also introduces an element of randomness that enhances the encryption strength.
The transformed data is then subjected to Huffman compression, further reducing its size while maintaining the cryptographic properties introduced by the dyadic distribution transformation. The encryption module generates two streams: a compressed main data stream and a secondary data stream containing information about the applied transformations. These two streams are then interleaved to produce the final encrypted output.
By applying this process to different components of the intrusion detection system, the encryption module ensures comprehensive protection. For instance, codewords collected by the codeword collector are encrypted before being stored or transmitted, making it extremely difficult for an attacker to discern the original data patterns even if they manage to intercept the encrypted codewords. Similarly, the sensitive information in the event database and signature database is encrypted, protecting historical data and known intrusion signatures from unauthorized access. In one embodiment, encryption module 5500 may also secure the output of prediction and validation subsystem 6320. Alerts generated by alerting module 5440 may be encrypted before transmission, ensuring that notifications about potential intrusions remain confidential as they are sent to security personnel or other monitoring systems. Encryption module 5500 can also be configured to encrypt the internal communications between different components of the intrusion detection system, creating a secure environment for data processing and analysis.
The use of the dyadic distribution-based encryption method provides several advantages in this context. It allows for simultaneous compression and encryption, reducing storage and bandwidth requirements while maintaining a high level of security. The method's resistance to statistical analysis attacks makes it particularly suitable for protecting the sensitive statistical data processed by the intrusion detection system. Furthermore, the ability to fine-tune the compression and encryption process through the transformation matrix allows the system to balance performance and security needs dynamically.
By integrating these new components with the existing architecture, the intrusion detection module becomes more robust, adaptive, and secure. The prediction and validation capabilities allow for proactive threat detection, while the continuous learning process ensures the system remains effective against emerging cybersecurity threats.
A data input layer 6400 serves as the entry point for various data streams into the subsystem. It may receive real-time codeword data from codeword collector 5410, historical event data from event database 5430, or other relevant information from various components of the intrusion detection module. This layer is responsible for initial data preprocessing, ensuring that incoming data is properly formatted and synchronized for further analysis.
Feature extractor 6410 processes the raw data from the input layer, identifying and extracting relevant features that are indicative of potential intrusions or anomalies. This component employs advanced algorithms to analyze statistical properties, temporal patterns, and contextual information within the data streams. The extracted features form the basis for both prediction and validation processes. Prediction engine 6420 utilizes machine learning models, such as neural networks or ensemble methods, to analyze the extracted features and predict potential intrusions before they fully manifest. This engine continuously updates its models based on new data and feedback from the validation process, allowing it to adapt to evolving threat landscapes and improve its predictive accuracy over time.
A validation engine 6430 works in tandem with prediction engine 6420 to assess the validity of both predicted and detected intrusions. It correlates the information from the prediction engine with known signatures, historical patterns, and contextual data to determine the likelihood of a true intrusion. This component plays a crucial role in reducing false positives and ensuring that the system's alerts are as accurate as possible. A decision engine 6440 acts as the central decision-making component of the subsystem. It aggregates the outputs from the prediction and validation engines, applying predefined rules and thresholds to determine whether an event should be classified as a validated intrusion, a false positive, or requires further investigation. The decision engine is also responsible for generating detailed reports and alerts based on its analysis.
Integration interface 6450 facilitates communication between prediction and validation subsystem 6320 and other components of the intrusion detection module. It sends validated intrusion data to the validated events store 6330 and information about false positives to the false positive event log 6340. Additionally, it interfaces with the alerting module 5440 to ensure that relevant information is promptly communicated to system administrators or security personnel.
By integrating these components, the prediction and validation subsystem significantly enhances the intrusion detection module's ability to identify and respond to potential security threats. Its machine learning-driven approach allows for more nuanced and accurate analysis, reducing false positives while improving the system's capability to detect sophisticated or novel attack patterns.
At the model training stage, a plurality of training data 6501 may be received by the machine learning training subsystem 6310. Data preprocessor 6502 may receive the input data (e.g., codewords, codeword vector inputs, intrusion event data, signature information) and perform various data preprocessing tasks on the input data to format the data for further processing. For example, data preprocessing can include, but is not limited to, tasks related to data cleansing, data deduplication, data normalization, data transformation, handling missing values, feature extraction and selection, mismatch handling, and/or the like. Data preprocessor 6502 may also be configured to create training dataset, a validation dataset, and a test set from the plurality of input data 6501. For example, a training dataset may comprise 80% of the preprocessed input data, the validation set 10%, and the test dataset may comprise the remaining 10% of the data. The preprocessed training dataset may be fed as input into one or more machine and/or deep learning algorithms 6503 to train a predictive model for object monitoring and detection.
During model training, training output 6504 is produced and used to measure the accuracy and usefulness of the predictive outputs. During this process a parametric optimizer 6505 may be used to perform algorithmic tuning between model training iterations. Model parameters and hyperparameters can include, but are not limited to, bias, train-test split ratio, learning rate in optimization algorithms (e.g., gradient descent), choice of optimization algorithm (e.g., gradient descent, stochastic gradient descent, of Adam optimizer, etc.), choice of activation function in a neural network layer (e.g., Sigmoid, ReLu, Tanh, etc.), the choice of cost or loss function the model will use, number of hidden layers in a neural network, number of activation unites in each layer, the drop-out rate in a neural network, number of iterations (epochs) in a training the model, number of clusters in a clustering task, kernel or filter size in convolutional layers, pooling size, batch size, the coefficients (or weights) of linear or logistic regression models, cluster centroids, and/or the like. Parameters and hyperparameters may be tuned and then applied to the next round of model training. In this way, the training stage provides a machine learning training loop.
In some implementations, various accuracy metrics may be used by the machine learning training subsystem 6310 to evaluate a model's performance. Metrics can include, but are not limited to, word error rate (WER), word information loss, speaker identification accuracy (e.g., single stream with multiple speakers), inverse text normalization and normalization error rate, punctuation accuracy, timestamp accuracy, latency, resource consumption, custom vocabulary, sentence-level sentiment analysis, multiple languages supported, cost-to-performance tradeoff, and personal identifying information/payment card industry redaction, to name a few. In one embodiment, the system may utilize a loss function 6560 to measure the system's performance. The loss function 6560 compares the training outputs with an expected output and determined how the algorithm needs to be changed in order to improve the quality of the model output. During the training stage, all outputs may be passed through the loss function 6560 on a continuous loop until the algorithms 6503 are in a position where they can effectively be incorporated into a deployed model 6515.
The test dataset can be used to test the accuracy of the model outputs. If the training model is establishing correlations that satisfy a certain criterion such as but not limited to quality of the correlations and amount of restored lost data, then it can be moved to the model deployment stage as a fully trained and deployed model 6510 in a production environment making predictions based on live input data 6511 (e.g., codewords, codeword vector inputs, intrusion event data, signature information). Further, model correlations and restorations made by deployed model can be used as feedback and applied to model training in the training stage, wherein the model is continuously learning over time using both training data and live data and predictions. A model and training database 6506 is present and configured to store training/test datasets and developed models. Database 6506 may also store previous versions of models.
According to some embodiments, the one or more machine and/or deep learning models may comprise any suitable algorithm known to those with skill in the art including, but not limited to: LLMs, generative transformers, transformers, supervised learning algorithms such as: regression (e.g., linear, polynomial, logistic, etc.), decision tree, random forest, k-nearest neighbor, support vector machines, Naïve-Bayes algorithm; unsupervised learning algorithms such as clustering algorithms, hidden Markov models, singular value decomposition, and/or the like. Alternatively, or additionally, algorithms 6503 may comprise a deep learning algorithm such as neural networks (e.g., recurrent, convolutional, long short-term memory networks, etc.).
In some implementations, the machine learning training system 6310 automatically generates standardized model scorecards for each model produced to provide rapid insights into the model and training data, maintain model provenance, and track performance over time. These model scorecards provide insights into model framework(s) used, training data, training data specifications such as chip size, stride, data splits, baseline hyperparameters, and other factors. Model scorecards may be stored in database(s) 6506.
Since the library consists of re-usable building sourceblocks, and the actual data is represented by reference codes to the library, the total storage space of a single set of data would be much smaller than conventional methods, wherein the data is stored in its entirety. The more data sets that are stored, the larger the library becomes, and the more data can be stored in reference code form.
As an analogy, imagine each data set as a collection of printed books that are only occasionally accessed. The amount of physical shelf space required to store many collections would be quite large, and is analogous to conventional methods of storing every single bit of data in every data set. Consider, however, storing all common elements within and across books in a single library, and storing the books as references codes to those common elements in that library. As a single book is added to the library, it will contain many repetitions of words and phrases. Instead of storing the whole words and phrases, they are added to a library, and given a reference code, and stored as reference codes. At this scale, some space savings may be achieved, but the reference codes will be on the order of the same size as the words themselves. As more books are added to the library, larger phrases, quotations, and other words patterns will become common among the books. The larger the word patterns, the smaller the reference codes will be in relation to them as not all possible word patterns will be used. As entire collections of books are added to the library, sentences, paragraphs, pages, or even whole books will become repetitive. There may be many duplicates of books within a collection and across multiple collections, many references and quotations from one book to another, and much common phrascology within books on particular subjects. If each unique page of a book is stored only once in a common library and given a reference code, then a book of 1,000 pages or more could be stored on a few printed pages as a string of codes referencing the proper full-sized pages in the common library. The physical space taken up by the books would be dramatically reduced. The more collections that are added, the greater the likelihood that phrases, paragraphs, pages, or entire books will already be in the library, and the more information in each collection of books can be stored in reference form. Accessing entire collections of books is then limited not by physical shelf space, but by the ability to reprint and recycle the books as needed for use.
The projected increase in storage capacity using the method herein described is primarily dependent on two factors: 1) the ratio of the number of bits in a block to the number of bits in the reference code, and 2) the amount of repetition in data being stored by the system. With respect to the first factor, the number of bits used in the reference codes to the sourceblocks must be smaller than the number of bits in the sourceblocks themselves in order for any additional data storage capacity to be obtained. As a simple example, 16-bit sourceblocks would require 216, or 65536, unique reference codes to represent all possible patterns of bits. If all possible 65536 blocks patterns are utilized, then the reference code itself would also need to contain sixteen bits in order to refer to all possible 65,536 blocks patterns. In such case, there would be no storage savings. However, if only 16 of those block patterns are utilized, the reference code can be reduced to 4 bits in size, representing an effective compression of 4 times (16 bits/4 bits=4) versus conventional storage. Using a typical block size of 512 bytes, or 4,096 bits, the number of possible block patterns is 24,096, which for all practical purposes is unlimited. A typical hard drive contains one terabyte (TB) of physical storage capacity, which represents 1,953,125,000, or roughly 231, 512 byte blocks. Assuming that 1 TB of unique 512-byte sourceblocks were contained in the library, and that the reference code would thus need to be 31 bits long, the effective compression ratio for stored data would be on the order of 132 times (4,096/31≈132) that of conventional storage.
With respect to the second factor, in most cases it could be assumed that there would be sufficient repetition within a data set such that, when the data set is broken down into sourceblocks, its size within the library would be smaller than the original data. However, it is conceivable that the initial copy of a data set could require somewhat more storage space than the data stored in a conventional manner, if all or nearly all sourceblocks in that set were unique. For example, assuming that the reference codes are 1/10th the size of a full-sized copy, the first copy stored as sourceblocks in the library would need to be 1.1 megabytes (MB), (1 MB for the complete set of full-sized sourceblocks in the library and 0.1 MB for the reference codes). However, since the sourceblocks stored in the library are universal, the more duplicate copies of something you save, the greater efficiency versus conventional storage methods. Conventionally, storing 10 copies of the same data requires 10 times the storage space of a single copy. For example, ten copies of a 1 MB file would take up 10 MB of storage space. However, using the method described herein, only a single full-sized copy is stored, and subsequent copies are stored as reference codes. Each additional copy takes up only a fraction of the space of the full-sized copy. For example, again assuming that the reference codes are 1/10th the size of the full-size copy, ten copies of a 1 MB file would take up only 2 MB of space (1 MB for the full-sized copy, and 0.1 MB each for ten sets of reference codes). The larger the library, the more likely that part or all of incoming data will duplicate sourceblocks already existing in the library.
The size of the library could be reduced in a manner similar to storage of data. Where sourceblocks differ from each other only by a certain number of bits, instead of storing a new sourceblock that is very similar to one already existing in the library, the new sourceblock could be represented as a reference code to the existing sourceblock, plus information about which bits in the new block differ from the existing block. For example, in the case where 512 byte sourceblocks are being used, if the system receives a new sourceblock that differs by only one bit from a sourceblock already existing in the library, instead of storing a new 512 byte sourceblock, the new sourceblock could be stored as a reference code to the existing sourceblock, plus a reference to the bit that differs. Storing the new sourceblock as a reference code plus changes would require only a few bytes of physical storage space versus the 512 bytes that a full sourceblock would require. The algorithm could be optimized to store new sourceblocks in this reference code plus changes form unless the changes portion is large enough that it is more efficient to store a new, full sourceblock.
It will be understood by one skilled in the art that transfer and synchronization of data would be increased to the same extent as for storage. By transferring or synchronizing reference codes instead of full-sized data, the bandwidth requirements for both types of operations are dramatically reduced.
In addition, the method described herein is inherently a form of encryption. When the data is converted from its full form to reference codes, none of the original data is contained in the reference codes. Without access to the library of sourceblocks, it would be impossible to reconstruct any portion of the data from the reference codes. This inherent property of the method described herein could obviate the need for traditional encryption algorithms, thereby offsetting most or all of the computational cost of conversion of data back and forth to reference codes. In theory, the method described herein should not utilize any additional computing power beyond traditional storage using encryption algorithms. Alternatively, the method described herein could be in addition to other encryption algorithms to increase data security even further.
In other embodiments, additional security features could be added, such as: creating a proprietary library of sourceblocks for proprietary networks, physical separation of the reference codes from the library of sourceblocks, storage of the library of sourceblocks on a removable device to enable easy physical separation of the library and reference codes from any network, and incorporation of proprietary sequences of how sourceblocks are read and the data reassembled.
In a step 6602, extract statistical features and temporal patterns from the received data. This step involves sophisticated data analysis techniques, including the use of the statistical analysis engine to identify relevant characteristics in the data stream. The feature extraction process considers factors such as codeword frequency, distribution patterns, and temporal relationships, which are crucial for detecting anomalies that may indicate potential intrusions.
In a step 6603, apply a machine learning model to predict potential intrusions based on the extracted features. This step leverages the capabilities of the prediction engine within the prediction and validation subsystem. The machine learning model, which could be a neural network, random forest, or another appropriate algorithm, analyzes the extracted features in the context of known intrusion patterns to identify potential security threats before they fully manifest.
In a step 6604, compare the predicted intrusions against the signature database for validation. This step involves the validation engine correlating the predictions with known intrusion signatures stored in the signature database. The comparison helps to confirm whether the predicted intrusions match known attack patterns or represent potentially new types of threats.
In a step 6605, calculate a confidence score for each potential intrusion. This score is based on multiple factors, including the strength of the match against known signatures, the severity of the potential threat, and the historical accuracy of similar predictions. The confidence score helps prioritize alerts and guide the response of security personnel.
In a step 6606, generate alerts for high-confidence potential intrusions. These alerts are created by the alerting module based on the output from the prediction and validation subsystem. High-confidence alerts are sent to system administrators or security personnel, providing them with detailed information about the potential intrusion, including the nature of the threat, affected systems, and recommended actions.
In a step 6607, update the machine learning model and signature database based on the validation results. This step is crucial for the continuous improvement of the system's predictive capabilities. Validated intrusions are added to the signature database, while the machine learning model is refined based on both successful predictions and false positives. This ongoing learning process ensures that the intrusion detection system becomes more accurate and effective over time, adapting to new types of threats and evolving attack patterns.
In a step 6702, analyze and processes the input data stream using the stream analyzer and data transformer. This step involves a detailed examination of the data to be encrypted, which may include codewords, event logs, signatures, or alerts. The stream analyzer identifies key characteristics of the data, while the data transformer prepares it for the encryption process.
In a step 6703, apply the dyadic distribution algorithm to generate a transformed main data stream and a secondary transformation data stream. This step is crucial for both compression and encryption. The dyadic distribution algorithm reshapes the data distribution to approach an ideal dyadic form, which not only compresses the data but also introduces a level of encryption by altering the data's statistical properties.
In a step 6704, use a secure random number generator to select transformations based on transformation matrix probabilities. This step introduces an element of randomness into the encryption process, enhancing its security. The transformation matrix, generated based on the characteristics of the input data, guides the selection of transformations, ensuring that the process is both secure and reversible.
In a step 6705, apply Huffman compression to the transformed main data stream. This step further reduces the size of the data while maintaining its encrypted state. Huffman compression is particularly effective when applied to data that has been transformed to approach a dyadic distribution, as it can achieve optimal compression ratios for such distributions.
In a step 6706, interleave the compressed main data stream with the secondary transformation data stream. This interleaving process combines the compressed and encrypted main data with the information needed to reverse the process, creating a single, secure data stream. The interleaving pattern itself can serve as an additional layer of security.
In a step 6707, transmit the interleaved data stream as compressed and encrypted output to secure storage or authorized recipients. This final step ensures that the sensitive data from the intrusion detection system-whether it's being stored for later analysis or transmitted to other security systems-remains protected. The compressed and encrypted format not only secures the data against unauthorized access but also reduces storage requirements and transmission bandwidth.
In a step 6802, preprocess and normalize the collected data, extracting relevant features. This step involves cleaning the data, handling missing values, and transforming it into a format suitable for machine learning algorithms. Feature extraction is a critical process where the system identifies key indicators of intrusions, such as unusual patterns in codeword sequences, statistical anomalies, or specific system state changes that are associated with security threats.
In a step 6803, split the preprocessed data into training, validation, and test sets. This division is essential for developing a robust and generalizable machine learning model. The training set is used to teach the model, the validation set helps in tuning the model's hyperparameters, and the test set provides an unbiased evaluation of the final model's performance.
In a step 6804, train the machine learning model on the training data set. This step may involve various types of models, such as neural networks, random forests, or other advanced algorithms suitable for intrusion detection. The training process involves iteratively adjusting the model's parameters to minimize prediction errors on the training data.
In a step 6805, validate the model's performance using the validation data set and adjusts hyperparameters as needed. This step is for fine-tuning the model and preventing overfitting. The system may use techniques like cross-validation to ensure the model performs well on unseen data.
In a step 6806, evaluate the final model performance on the test data set. This step provides an unbiased assessment of how well the model generalizes to new, unseen data. Performance metrics such as accuracy, precision, recall, and FI score are typically used to gauge the model's effectiveness in detecting intrusions while minimizing false positives.
In a step 6807, deploy the trained model to the prediction and validation subsystem and integrates it with real-time data streams. This final step involves incorporating the model into the operational intrusion detection system, where it can analyze live data streams to predict and validate potential intrusions. The integration ensures that the model can process incoming data in real-time, providing timely alerts and continuously learning from new data to improve its performance over time.
It will be recognized by a person skilled in the art that the methods described herein can be applied to data in any form. For example, the method described herein could be used to store genetic data, which has four data units: C, G, A, and T. Those four data units can be represented as 2 bit sequences: 00, 01, 10, and 11, which can be processed and stored using the method described herein.
It will be recognized by a person skilled in the art that certain embodiments of the methods described herein may have uses other than data storage. For example, because the data is stored in reference code form, it cannot be reconstructed without the availability of the library of sourceblocks. This is effectively a form of encryption, which could be used for cyber security purposes. As another example, an embodiment of the method described herein could be used to store backup copies of data, provide for redundancy in the event of server failure, or provide additional security against cyberattacks by distributing multiple partial copies of the library among computers are various locations, ensuring that at least two copies of each sourceblock exist in different locations within the network.
According to the embodiment, signature correlation engine 5460 obtains a plurality of information associated with known vulnerabilities, exploits, malware, and malicious entities from various third party and/or external sources at step 5502. This type of information may be referred to as threat intelligence, and may be obtained from one or more threat intelligence systems. Correlation engine 5460 can correlate the statistical information and other information in the historical event data with the threat intelligence data to identify patterns in a malicious actor's behavior and the statistical information associated with the detection thereof. At step 5503, signature correlation engine 5460 generates a signature associated with a known vulnerability, exploit, malware, or malicious actor based on the historical anomalous event data. For example, a signature may include a computed divergence, a computed probability distribution, both associated with a data stream, wherein the data stream comprises a plurality of codewords. The signature may further comprise metadata that provides contextual information about the anomalous event. As a last step 5504, the generated signature may be stored in a signature database 5470.
If instead, at 5503 a match is found, then the process proceeds to step 5605 wherein alerting module 5440 generates an intrusion alert, the intrusion alert comprising the anomalous event data. The intrusion may further comprise information associated with the matched signature, such as threat actors, methods, and/or the like. As a last step 5506 alerting module can send the alert to a security monitoring system which may take further action or investigation.
Generally, the techniques disclosed herein may be implemented on hardware or a combination of software and hardware. For example, they may be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, on an application-specific integrated circuit (ASIC), or on a network interface card.
Software/hardware hybrid implementations of at least some of the aspects disclosed herein may be implemented on a programmable network-resident machine (which should be understood to include intermittently connected network-aware machines) selectively activated or reconfigured by a computer program stored in memory. Such network devices may have multiple network interfaces that may be configured or designed to utilize different types of network communication protocols. A general architecture for some of these machines may be described herein in order to illustrate one or more exemplary means by which a given unit of functionality may be implemented. According to specific aspects, at least some of the features or functionalities of the various aspects disclosed herein may be implemented on one or more general-purpose computers associated with one or more networks, such as for example an end-user computer system, a client computer, a network server or other server system, a mobile computing device (e.g., tablet computing device, mobile phone, smartphone, laptop, or other appropriate computing device), a consumer electronic device, a music player, or any other suitable electronic device, router, switch, or other suitable device, or any combination thereof. In at least some aspects, at least some of the features or functionalities of the various aspects disclosed herein may be implemented in one or more virtualized computing environments (e.g., network computing clouds, virtual machines hosted on one or more physical computing machines, or other appropriate virtual environments).
Referring now to
In one aspect, computing device 10 includes one or more central processing units (CPU) 12, one or more interfaces 15, and one or more busses 14 (such as a peripheral component interconnect (PCI) bus). When acting under the control of appropriate software or firmware, CPU 12 may be responsible for implementing specific functions associated with the functions of a specifically configured computing device or machine. For example, in at least one aspect, a computing device 10 may be configured or designed to function as a server system utilizing CPU 12, local memory 11 and/or remote memory 16, and interface(s) 15. In at least one aspect, CPU 12 may be caused to perform one or more of the different types of functions and/or operations under the control of software modules or components, which for example, may include an operating system and any appropriate applications software, drivers, and the like.
CPU 12 may include one or more processors 13 such as, for example, a processor from one of the Intel, ARM, Qualcomm, and AMD families of microprocessors. In some aspects, processors 13 may include specially designed hardware such as application-specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), field-programmable gate arrays (FPGAs), and so forth, for controlling operations of computing device 10. In a particular aspect, a local memory 11 (such as non-volatile random access memory (RAM) and/or read-only memory (ROM), including for example one or more levels of cached memory) may also form part of CPU 12. However, there are many different ways in which memory may be coupled to system 10. Memory 11 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, and the like. It should be further appreciated that CPU 12 may be one of a variety of system-on-a-chip (SOC) type hardware that may include additional hardware such as memory or graphics processing chips, such as a QUALCOMM SNAPDRAGON™ or SAMSUNG EXYNOS™ CPU as are becoming increasingly common in the art, such as for use in mobile devices or integrated devices.
As used herein, the term “processor” is not limited merely to those integrated circuits referred to in the art as a processor, a mobile processor, or a microprocessor, but broadly refers to a microcontroller, a microcomputer, a programmable logic controller, an application-specific integrated circuit, and any other programmable circuit.
In one aspect, interfaces 15 are provided as network interface cards (NICs). Generally, NICs control the sending and receiving of data packets over a computer network; other types of interfaces 15 may for example support other peripherals used with computing device 10. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, graphics interfaces, and the like. In addition, various types of interfaces may be provided such as, for example, universal serial bus (USB), Serial, Ethernet, FIREWIRE™, THUNDERBOLT™, PCI, parallel, radio frequency (RF), BLUETOOTH™, near-field communications (e.g., using near-field magnetics), 802.11 (WiFi), frame relay, TCP/IP, ISDN, fast Ethernet interfaces, Gigabit Ethernet interfaces, Serial ATA (SATA) or external SATA (ESATA) interfaces, high-definition multimedia interface (HDMI), digital visual interface (DVI), analog or digital audio interfaces, asynchronous transfer mode (ATM) interfaces, high-speed serial interface (HSSI) interfaces, Point of Sale (POS) interfaces, fiber data distributed interfaces (FDDIs), and the like. Generally, such interfaces 15 may include physical ports appropriate for communication with appropriate media. In some cases, they may also include an independent processor (such as a dedicated audio or video processor, as is common in the art for high-fidelity A/V hardware interfaces) and, in some instances, volatile and/or non-volatile memory (e.g., RAM).
Although the system shown in
Regardless of network device configuration, the system of an aspect may employ one or more memories or memory modules (such as, for example, remote memory block 16 and local memory 11) configured to store data, program instructions for the general-purpose network operations, or other information relating to the functionality of the aspects described herein (or any combinations of the above). Program instructions may control execution of or comprise an operating system and/or one or more applications, for example. Memory 16 or memories 11, 16 may also be configured to store data structures, configuration data, encryption data, historical system operations information, or any other specific or generic non-program information described herein.
Because such information and program instructions may be employed to implement one or more systems or methods described herein, at least some network device aspects may include nontransitory machine-readable storage media, which, for example, may be configured or designed to store program instructions, state information, and the like for performing various operations described herein. Examples of such nontransitory machine-readable storage media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as optical disks, and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM), flash memory (as is common in mobile devices and integrated systems), solid state drives (SSD) and “hybrid SSD” storage drives that may combine physical components of solid state and hard disk drives in a single hardware device (as are becoming increasingly common in the art with regard to personal computers), memristor memory, random access memory (RAM), and the like. It should be appreciated that such storage means may be integral and non-removable (such as RAM hardware modules that may be soldered onto a motherboard or otherwise integrated into an electronic device), or they may be removable such as swappable flash memory modules (such as “thumb drives” or other removable media designed for rapidly exchanging physical storage devices), “hot-swappable” hard disk drives or solid state drives, removable optical storage discs, or other such removable media, and that such integral and removable storage media may be utilized interchangeably. Examples of program instructions include both object code, such as may be produced by a compiler, machine code, such as may be produced by an assembler or a linker, byte code, such as may be generated by for example a JAVA™ compiler and may be executed using a Java virtual machine or equivalent, or files containing higher level code that may be executed by the computer using an interpreter (for example, scripts written in Python, Perl, Ruby, Groovy, or any other scripting language).
In some aspects, systems may be implemented on a standalone computing system. Referring now to
In some aspects, systems may be implemented on a distributed computing network, such as one having any number of clients and/or servers. Referring now to
In addition, in some aspects, servers 32 may call external services 37 when needed to obtain additional information, or to refer to additional data concerning a particular call. Communications with external services 37 may take place, for example, via one or more networks 31. In various aspects, external services 37 may comprise web-enabled services or functionality related to or installed on the hardware device itself. For example, in one aspect where client applications 24 are implemented on a smartphone or other electronic device, client applications 24 may obtain information stored in a server system 32 in the cloud or on an external service 37 deployed on one or more of a particular enterprise's or user's premises. In addition to local storage on servers 32, remote storage 38 may be accessible through the network(s) 31.
In some aspects, clients 33 or servers 32 (or both) may make use of one or more specialized services or appliances that may be deployed locally or remotely across one or more networks 31. For example, one or more databases 34 in either local or remote storage 38 may be used or referred to by one or more aspects. It should be understood by one having ordinary skill in the art that databases in storage 34 may be arranged in a wide variety of architectures and using a wide variety of data access and manipulation means. For example, in various aspects one or more databases in storage 34 may comprise a relational database system using a structured query language (SQL), while others may comprise an alternative data storage technology such as those referred to in the art as “NoSQL” (for example, HADOOP CASSANDRA™, GOOGLE BIGTABLE™, and so forth). In some aspects, variant database architectures such as column-oriented databases, in-memory databases, clustered databases, distributed databases, or even flat file data repositories may be used according to the aspect. It will be appreciated by one having ordinary skill in the art that any combination of known or future database technologies may be used as appropriate, unless a specific database technology or a specific arrangement of components is specified for a particular aspect described herein. Moreover, it should be appreciated that the term “database” as used herein may refer to a physical database machine, a cluster of machines acting as a single database system, or a logical database within an overall database management system. Unless a specific meaning is specified for a given use of the term “database”, it should be construed to mean any of these senses of the word, all of which are understood as a plain meaning of the term “database” by those having ordinary skill in the art.
Similarly, some aspects may make use of one or more security systems 36 and configuration systems 35. Security and configuration management are common information technology (IT) and web functions, and some amount of each are generally associated with any IT or web systems. It should be understood by one having ordinary skill in the art that any configuration or security subsystems known in the art now or in the future may be used in conjunction with aspects without limitation, unless a specific security 36 or configuration system 35 or approach is specifically required by the description of any specific aspect.
In various aspects, functionality for implementing systems or methods of various aspects may be distributed among any number of client and/or server components. For example, various software modules may be implemented for performing various functions in connection with the system of any particular aspect, and such modules may be variously implemented to run on server and/or client components.
The skilled person will be aware of a range of possible modifications of the various aspects described above. Accordingly, the present invention is defined by the claims and their equivalents.
Priority is claimed in the application data sheet to the following patents or patent applications, each of which is expressly incorporated herein by reference in its entirety: Ser. No. 18/770,652Ser. No. 18/503,135Ser. No. 18/305,305Ser. No. 18/190,044Ser. No. 17/875,201Ser. No. 17/514,913Ser. No. 17/404,699Ser. No. 16/455,655Ser. No. 17/458,747Ser. No. 16/923,03963/027,166Ser. No. 16/716,098Ser. No. 16/200,466Ser. No. 15/975,74162/578,82462/926,72363/388,411Ser. No. 17/727,91363/485,51863/232,041Ser. No. 17/234,007Ser. No. 17/180,43963/140,111Ser. No. 18/436,045Ser. No. 18/460,55363/485,514Ser. No. 18/161,080
| Number | Date | Country | |
|---|---|---|---|
| 62578824 | Oct 2017 | US | |
| 63027166 | May 2020 | US | |
| 62926723 | Oct 2019 | US | |
| 63388411 | Jul 2022 | US | |
| 63485518 | Feb 2023 | US | |
| 63232041 | Aug 2021 | US | |
| 63140111 | Jan 2021 | US | |
| 63485514 | Feb 2023 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 18305305 | Apr 2023 | US |
| Child | 18503135 | US | |
| Parent | 17514913 | Oct 2021 | US |
| Child | 17875201 | US | |
| Parent | 17458747 | Aug 2021 | US |
| Child | 17875201 | US | |
| Parent | 16455655 | Jun 2019 | US |
| Child | 16716098 | US | |
| Parent | 17404699 | Aug 2021 | US |
| Child | 17727913 | US | |
| Parent | 17875201 | Jul 2022 | US |
| Child | 18161080 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 18770652 | Jul 2024 | US |
| Child | 18919468 | US | |
| Parent | 18503135 | Nov 2023 | US |
| Child | 18770652 | US | |
| Parent | 18190044 | Mar 2023 | US |
| Child | 18305305 | US | |
| Parent | 17875201 | Jul 2022 | US |
| Child | 18190044 | US | |
| Parent | 17404699 | Aug 2021 | US |
| Child | 17514913 | US | |
| Parent | 16455655 | Jun 2019 | US |
| Child | 17404699 | US | |
| Parent | 16200466 | Nov 2018 | US |
| Child | 16455655 | US | |
| Parent | 15975741 | May 2018 | US |
| Child | 16200466 | US | |
| Parent | 16923039 | Jul 2020 | US |
| Child | 17458747 | US | |
| Parent | 16716098 | Dec 2019 | US |
| Child | 16923039 | US | |
| Parent | 17727913 | Apr 2022 | US |
| Child | 16455655 | US | |
| Parent | 17234007 | Apr 2021 | US |
| Child | 17404699 | US | |
| Parent | 17180439 | Feb 2021 | US |
| Child | 17234007 | US | |
| Parent | 16923039 | Jul 2020 | US |
| Child | 17180439 | US | |
| Parent | 18436045 | Feb 2024 | US |
| Child | 18919468 | US | |
| Parent | 18460553 | Sep 2023 | US |
| Child | 18436045 | US | |
| Parent | 18161080 | Jan 2023 | US |
| Child | 18460553 | US | |
| Parent | 17234007 | Apr 2021 | US |
| Child | 18460553 | US |
