System for real-time cross-domain system packet filtering

A system for filtering a digital signal transmitted in a protocol featuring multi-level packetization from a first server to a second server. The first server is coupled to the second server via a one-way data link. The system includes a filter having an input for receiving the digital signal and an output. The filter is configured to analyze the digital video signal and determine whether the digital signal violates one or more predetermined criteria. The filter may be within the first server, or alternatively, within the second server. The predetermined criteria may be unauthorized security level information included within metadata transmitted with the digital video signal. The predetermined criteria may also be format information that, when not conformed to, indicates potential malware or other bad content included within the digital video signal. The filter provides low data transfer latency and/or decoupling of data filter latency from data transfer latency.

FIELD OF INVENTION

This invention relates generally to a system for real-time cross-domain system packet filtering, and in particular, a system for real-time cross-domain system filtering of packets of digital information.

BACKGROUND OF THE INVENTION

One form of conventional digital video transmission involves transmitting an MPEG-2 Transport Stream (TS) consisting of a series of digital packets of information. The information stored with the TS can include Key Length Value (KLV) metadata. In some situations, the TS may be transmitted from a higher security domain to a lower security domain. In other situations, the TS may be transmitted from a lower security domain to a higher security domain. The TS packets often are included within UDP packets for transmission.

When the TS is transmitted from a higher security domain to a lower security domain, it is important to ensure that the transmission of the content of such TS does not violate any security policy. For example, the video content of TS may include KLV metadata indicating that the associated video is designated Top Secret. Thus, it is important to ensure that the transfer across the security domains does not permit unauthorized, uncontrolled distribution of material, e.g., that such Top Secret video is not transmitted to a lower security domain. Similarly, when the TS is transmitted from a lower security domain to a higher security domain, it is important to ensure that no malware or other inappropriate information/data (e.g., botnets or “dirty” words) exists within the KLV metadata.

Highly engineered solutions, such as the Owl Computing Technologies Dual Diode, (described in U.S. Pat. No. 8,068,415, the disclosure of which is incorporated herein by reference) provide a direct point-to-point optical link between network domains in the low-to-high direction or in the low-to-high direction. The unidirectionality of the data transfer is enforced in the circuitry of the network interface cards at both network endpoints and in the cable interconnects. In this way, the hardware provides an added layer of assurance of unidirectional information flow and non-bypassable operation. In contrast to software based one-way data transfer systems, it is easy to prove that data is not bypassing the Dual Diode.

In such systems, shown in block diagram form inFIG. 1, a first server (the Blue Server)101includes a transmit application102for sending data across a one-way data link, e.g., optical link104, from a first network domain coupled to server101to a second network domain coupled to server111. First server101also includes a transmit (here a phototransmission) component, e.g., optical emitter103. Transmit application102provides data to the optical emitter for transmission across the optical link104. A second server (the Red Server)111includes a receive (here a photodetection) component, e.g., optical detector113, for receiving data from the optical link104, which data is then provided to the receive application112for further processing. The first server101is only able to transmit data to second server111, since it does not include any receive circuitry (e.g., an optical detector comparable to detector113) and the second server111is only able to receive data from first server101, since it does not include any transmit circuitry (e.g., an optical emitter comparable to emitter103).

It is an object of the present invention to provide a system for real-time cross-domain system packet filtering.

SUMMARY OF THE INVENTION

The present invention provides a system for transmitting a digital signal, which may be a video signal, from a first server, which may have a first security level, to a second server, which may have a second different security level. The first server is coupled to the second server via a one-way data link. The system includes a filter having an input for receiving the digital signal and an output. The filter is configured to analyze the digital signal and determine whether the digital signal violates one or more predetermined criteria. In an embodiment, the filter is within the first server. In another embodiment, the filter is within the second server. The filter may be configured to block the digital signal from passing to the output of the filter when the digital signal violates the one or more predetermined criteria. In addition, the filter may be also configured to generate an alert message and/or record a message in a log file when the digital signal violates the one or more predetermined criteria. Alternatively, the filter may be configured to allow the digital signal to pass to the output of the filter and to generate an alert message and/or record a message in a log file when the digital signal violates the one or more predetermined criteria. The one or more predetermined criteria may comprise a format structure of the digital signal and/or a predetermined security level. In a further embodiment, the first security level may be higher than the second security level and the predetermined security level may be the same as the second security level. In a still further embodiment, the filter analyzes the digital signal by extracting metadata included within the digital signal and compares a content of the metadata with the one or more predetermined criteria to determine the violation. The digital signal may comprise Transport Stream packets within UDP packets. The metadata may comprise KLV data within the Transport Stream packets. The digital signal may comprise a sequence of blocks of information and the filter may prevent each block of information from passing to the output of the filter until after the determination of whether the digital signal violates one or more predetermined criteria is complete. The digital signal may comprise a sequence of blocks of information, and the filter may immediately forward each block of information to the output of the filter and perform the determination of whether the digital signal violates one or more predetermined criteria in a background operation.

In a still further embodiment, the invention is a system for transmitting a digital signal, which may be a digital video signal. The system includes a first server having a first security level and a filter within the first server having an input for receiving a digital signal and an output, wherein the filter is configured to analyze the digital signal and determine whether the digital signal violates one or more predetermined criteria. The system also includes a one-way transmission system having an input coupled to the output of the filter and an output; and a second server, which may have a second different security level, the second server being coupled to the output of the one-way transmission system.

In yet another embodiment, the invention is a system for transmitting a digital signal, which may be a digital video signal. The system includes a first server having a first security level and a one-way transmission system having an input within the first server for receiving a digital signal and an output. The system also includes a second server, which may have a second different security level, the second server being coupled to the output of the one-way transmission system, and a filter within the second server having an input coupled to the output of the one-way transmission system and an output, wherein the filter is configured to analyze the digital signal and determine whether the digital signal violates one or more predetermined criteria.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the present disclosure, like reference numbers refer to like elements throughout the drawings, which illustrate various exemplary embodiments of the present invention. This disclosure refers to domains of differing security levels by referring to a higher confidentiality level domain and a lower confidentiality domain. As one of ordinary skill in the art will readily recognize, the present invention as applicability for any cross-domain solution, including transmission between two domains having the same security level, and the discussion of higher and lower confidentiality is merely illustrative of the preferred embodiments.

A UDP packet data filter is described herein which detects potential security violations in packets, preferably MPEG-2 Transport Stream (TS) packets, carrying metadata, preferably Key Length Value (KLV). In overview, this filter may perform the following steps:1. Scan each UDP packet for TS packet headers;2. Construct Packetized Elementary Stream (PES) packet headers from TS packet payloads;3. Parses KLV metadata to identify any security tags present therein; and4. Based on an analysis of the security tags: a. Blocks UDP packets from transmission, or b. Provides auditing and alert messages on detection of data security violations (This allows the filter to forward UDP packets in real time while scanning processes proceed in parallel or on an independent thread.)

In addition, in addition to blocking based on security violations, the filter disclosed herein is also capable of blocking transmission of UDP blocks based on other characteristics of the received UDP blocks, as discussed in more particular detail below. In terms of the options presented above of either immediately blocking UDP packets or instead providing auditing and alert messaging upon the detection of data security violations, the inventors have found that while only minimal latency in UDP packet forwarding is tolerable to views of the filtered video stream, much higher latency values are generally tolerable for detection of security violations that trigger audit and alert methods. The second option above provides a relatively low transfer latency for the video stream and in effect decouples the transfer latency from the filter processing latency.

Referring now to the drawings and in particular to the embodiment shown inFIG. 2, a system200for transferring information from a higher confidentiality level domain250to a lower confidentiality level domain260includes a send server201within the higher confidentiality level domain250and a receive server211within the lower confidentiality level domain260. The send server201is connected to the receive server211via an optical link104, in the same manner as the conventional system shown inFIG. 1. Send server201receives information for transfer, e.g., TS packets included within UDP packets and constituting a video signal, at an input230that is coupled to a filter210. Filter210processes the received UDP packets and determines, based on a comparison of the particular content thereof with certain predetermined criteria, whether the UDP packets include information that indicates that the cross-domain transfer constitutes a security violation or otherwise has characteristics indicating that malware or other undesired content is included within the packets. As discussed herein, the predetermined criteria may relate to one or more of the following: packet formatting; metadata message content (including but not limited to a stated security level); metadata message formatting.

If filter210identifies a security violation or undesired content, filter210may block the UDP packets from being passed as an output of the filter210. Filter210may also generate an alert message and/or make an entry in an audit log220upon the identification of a security violation or undesired content. In a further embodiment, filter210may strip the metadata from the UDP packets, in whole or in part, to remove any information included therein which should not be released into the lower confidentiality domain260. For example, metadata including information having a high level of precision may be modified to have a much lower level of precision or even to materially change the information. As one of ordinary skill in the art will readily recognize, there are many ways to modify such information to either reduce the precision thereof or to intentionally obfuscate such information. As an example, such metadata may include location information. Using the present invention, such location information could be modified to have less precision (making it difficult to precisely target such location) or could be modified to reflect a completely different location (with the same effect). The output of filter210is provided to a transmit application102, and then to a transmit component103. Transmit application102and transmit component103operate in the same manner as in theFIG. 1system. From transmit component103, the filtered signal is then provided, via the optical link104, to optical detector113in the receive server211and then, in turn, to receive application112for processing. After processing by receive application112, the received signal comprising a filtered TS signal is provided to an output240of the receive server211for further processing, viewing, etc. As evident inFIG. 2, the filtered TS signal in the form of UDP packets is provided across the boundary270between the higher confidentiality domain250and the lower confidentiality domain260.

Filter210analyzes the UDP packets comprising the TS signal and may be configured to analyze the received UDP packets and perform one of three possible operations:1. Forward received packets in real time but copy to memory for analysis and then, if “bad” packets are identified, block transfer of additional received packets immediately (and, optionally, record an identified security violation or undesired content occurrence in a log and/or generate an alert message). This operation decouples transfer latency from filter latency while limiting the bandwidth of bad packets passed forward.2. Always forward the received packets, but copy any “bad” packets to a memory for further analysis (and generate an alert message upon identification of a security violation or undesired content occurrence). This operation maintains access to a live video feed while fully accepting the risk that data contains security violations. This operation may also be used as an optional override feature in the case of a false positive finding in the first option above (or in the situation where the live video feed is needed no matter the risk).3. Queue all packets for analysis and block transfer of packets which are identified as “bad.” This provides the most secure operation but creates the longest latency because all packets must be cached and analyzed before being forwarded.

In connection with operations1and3above, filter210may also strip out the metadata, in whole or in part, if the particular content of such metadata contains information which should not be released into the lower security domain.

The first operation is discussed in more detail below with respect toFIG. 4. As one of ordinary skill in the art will readily recognize, the second and third operations are variants of the first operation and the audit log220may be used with any of these operations, in further embodiments, to record all instances of security violations or undesired content occurrences.

Referring now to the embodiment shown inFIG. 3, a system300for transferring information from a lower confidentiality level domain350to a higher confidentiality level domain360includes a send server301within the lower confidentiality level domain350and a receive server311within the higher confidentiality level domain360. As with the embodiment ofFIG. 1, the send server301is connected to the receive server311via an optical link104, in the same manner as the conventional system shown inFIG. 1. Send server301receives information for transfer, e.g., TS data included within UDP packets and constituting one or more video signals, at an input330that is coupled to transmit application102and then to transmit component103. Transmit application102and transmit component103operate in the same manner as in theFIG. 1system. From transmit component103, the signal is then provided, via the optical link104, to optical detector113in the receive server311and then, in turn, to receive application112for processing. After processing by receive application112, the signal is provided to filter310, which is optionally coupled to an audit log320, which, as discussed below, allows the system to record instances of security violations. Filter310operates in an identical manner to filter210ofFIG. 2, as discussed in more detail with respect toFIG. 4. The filtered TS signal is provided by filter310to an output340of the receive server211for further processing, viewing, etc. As evident inFIG. 3, the video signal in the form of TS packets within UDP packets is provided across the boundary370between the higher confidentiality domain350and the lower confidentiality domain360.

In a first mode of operation, the filter disclosed herein (filter210inFIG. 2and filter310inFIG. 3) operates on received UDP packets in accordance with the flowchart400shown inFIG. 4. As shown inFIG. 5, a UDP packet510comprises a number (seven) of TS packets520. Each TS packet520includes a sync byte530, a packet header540and a packet payload550. The packet payload consists of a number of Packetized Elementary Stream (PES) packets560. The UDP packet is received at step401inFIG. 4. The UDP packet payload is extracted at step402and tested at step403. If the TS sync of the TS packets within the current UDP packet is found to be correct at step404, the individual TS packets are then sequentially processed in a loop starting at step405. The TS sync byte has a fixed value, i.e., 0x47h, and is always, without exception, the first byte of each TS packet. If the TS sync is not found to be correct at step404(i.e., if the proper value is not found at the seven expected locations within each UDP packet), the content of the received UDP packet is bad and processing proceeds by optionally logging the TS error at step406(within the audit log220) and then moving back to step401to receive and process the next UDP packet (the bad UDP packet is not forwarded).

At step405, the current TS packet is processed and then TS parsing is tested at step407by ensuring that each TS packet contains the proper internal attributes. If the current TS packet is not okay at step407, the content of the received UDP packet is bad and processing proceeds to step406for optional logging of the error and then back to step401to receive the next UDP packet. If the current TS packet is okay at step407, processing proceeds to step408, which checks if PES processing is enabled (if PES processing is not enabled, then the filter blocks passage of the UDP packets only based on lack of proper formatting of the received packet, e.g., TS sync or TS parse errors, and not based on any metadata content). If not enabled, processing moves to step409, which determines if there are more TS packets to analyze. If there are more TS packets, processing loops back to step405. Otherwise, if all the TS packets within the current UDP packet have been processed, processing moves to step410, where a check of the violation flag is made. If the violation flag has not been set, the current UDP packet is forwarded as an output at step411and processing reverts to step401to receive and process the next UDP packet. If a violation flag has been set, processing moves to step401without forwarding the current UDP packet by skipping step411.

Continuing withFIG. 4, when PES processing is implemented (and identified at step408), the payload of the current TS packet is retrieved at step412and the PES data of interest, e.g., KLV metadata, is accumulated at step413. A diagram showing how the PES data is stored within the payload portions of the TS packets within the UDP packets is shown inFIG. 6. InFIG. 6, a series of UDP packets610,611,612each include seven TS packets620. Four different types of TS packet payloads are shown inFIG. 6, including Video PES630, Audio PES640, Sync Meta PES650and Async Meta PES660. The Sync Meta PES650and Async Meta PES660packets may constitute the KLV metadata. The packets are not evenly distributed within the UDP packets, so a complete PES packet may transcend a single UDP packet. Thus, the filter disclosed herein accumulates PES data by extracting the appropriate packet payloads, in a manner as shown inFIG. 6, as each TS packet is processed. At step414ofFIG. 4, it is determined if the current PES packet is complete (the current PES packet, for example, comprising a predetermined number of associated TS packet payloads such as the four Sync Meta PES packet payloads650shown inFIG. 6or the three Async Meta PES packet payloads shown inFIG. 6). If the current PES packet is not complete, processing returns to step409discussed above for continued operation on the present or next UDP packet, depending on the outcome of step409. If the current PES packet is found to be complete at step414, the PES packet is processed at step415, the payload is extracted at step416and the payload is analyzed at step417.

Continuing withFIG. 4, if, at step420, the content of the current PES packet payload is found to constitute a security violation, a PES error is (optionally) logged at step421, the violation flag is set at step422and processing reverts to step401to process the next UDP packet. An alert message may also be generated upon the setting of the violation flag. The current UDP packet is not transmitted in this embodiment and, since the violation flag is set, subsequent UDP packets will not be transmitted until the security violation is cleared. In the alternative, the metadata may be stripped from the UDP packets and the modified versions of the UDP packets, which do not include the metadata content found to constitute a security violation, may be alternatively transmitted from the filter (instead of blocking the transmission of the originally received UDP packets which include the bad content). If the contents of the current PES packet payload is not found to constitute a security violation at step420, the status of the violation flag is checked at step419, and if set, it is cleared at step418. Thereafter, processing returns to step409for continued processing as discussed above.

The system disclosed herein can be configured to identify security violations in a UDP video packet stream which are identified, for example, by comparing the security level of the received video signal as embedded in the KLV data with the security level of the domain receiving the video signal. Of course, as one of ordinary skill in the art will readily recognize, any information stored within the KLV data, including but not limited to security level, may be compared with predetermined criteria in the system disclosed herein to determine whether the associated video signal is authorized or not (with unauthorized video constituting a security violation). Further, the system disclosed herein can also identify improperly formatted video data in a UDP video packet stream which could constitute malware, botnets, or other potentially harmful information, generally referred to herein as “undesired content.” Once the security violation or undesired content is identified, the filter may block all subsequent UDP blocks until the security violation or undesired content ceases. Alternatively, the filter can allow the UDP blocks to pass, while logging and/or signaling the occurrence of the security violation and/or undesired content. The filter can be set, in one mode, to pass UDP blocks upon receipt and process such blocks in the background, in which case a limited number of “bad” blocks, i.e., blocks with a security violation or undesired content, might be passed before the existence of the bad block or blocks is identified and the UDP block stream stopped. In an alternative mode, the UDP blocks may be queued and only released once the associated metadata is analyzed and cleared. The former mode provides better transfer latency for the UDP blocks, but the latter mode ensures that no “bad” blocks are passed. In a still further alternative mode, the UDP blocks may be continually passed, but upon detection of a security violation or undesired content, the existence thereof can be logged and/or an alert message may be generated.

As one of skill in the art will readily recognize, KLV is a data encoding standard that is often used to embed information in video signal feeds. KLV is defined in SMPTE 336M-2007 (Data Encoding Protocol Using Key-Length Value) as approved by the Society of Motion Picture and Television Engineers. According to this standard, items are encoded into Key-Length-Value fields, where the key field identifies the data, length field specifies the length of the data, and value field is the data itself. The allowable entries for each of the Key, Length and Value fields may be tabulated in libraries. According to the present embodiment, if a KLV object fails to conform to the defined standards as tabulated in an associated library, such object may be treated as a security violation.

The embodiment described above operates on TS data transmitted as UDP packets. As one of ordinary skill in the art will readily recognize, the filtering operations presented herein may be applied to any digital data transmitted in a protocol featuring multi-level packetization. As such, although the present invention has been particularly shown and described with reference to the preferred embodiments and various aspects thereof, it will be appreciated by those of ordinary skill in the art that various changes and modifications may be made without departing from the spirit and scope of the invention. It is intended that the appended claims be interpreted as including the embodiments described herein, the alternatives mentioned above, and all equivalents thereto.