In-line inspection of multi-part file transmissions and cybersecurity enforcement

Abstract

Separating the recognition of multipart file transmissions for different applications from traffic processing at the granularity of individual application-layer sessions facilitates efficient cybersecurity enforcement in multipart file transmissions. A protocol-based multipart file transmission regulator ("Regulator") determines per-session message processing actions to prevent completion of the multipart file transmission based on the protocol of the application identified for the session until a cybersecurity analysis can be performed. The Regulator then communicates the message processing actions to network components supporting the session. The Regulator maintains information and file chunks for active sessions in a data store and uses the data store to determine whether conditions are met for requiring a cybersecurity analysis for the multipart file transmission. Once a cybersecurity analysis decision is obtained, the Regulator provides a decision or decision-based instruction to network components that ensure the multipart file transmission complies with cybersecurity policy.

Description

[Technical Field]

[0001] This disclosure relates generally to the transmission of digital information (eg, CPC class H04L) and to network architectures or network communication protocols for managing network security (eg, subclass H04L63 / 20). [Background technology]

[0002] Several companies offer file management solutions involving the uploading and downloading of large files. These are also called file storage services and cloud storage services. Different services may utilize software components that implement different protocols for multipart file transmission (i.e., transmitting different parts or "chunks" of a file over multiple sessions). A client component on the sending endpoint breaks the file into chunks and then transmits the different chunks in different sessions (i.e., application-layer sessions) established with the receiving endpoint.

[0003] Network cybersecurity components (e.g., firewalls, security access proxies, secure web proxies) process network traffic to identify cybersecurity threats and identify violations of cybersecurity policies. When processing network traffic corresponding to multipart file transmissions, the network cybersecurity components collect file chunks and metadata to reassemble the files for cybersecurity analysis. [Brief explanation of the drawings]

[0004] Embodiments of the present disclosure may be better understood with reference to the accompanying drawings. [Figure 1A]1A-1B are diagrams of an exemplary system for efficiently enforcing cybersecurity compliance for multi-part file transmissions. FIG. 1A illustrates exemplary components of the system. [Figure 1B] FIG. 1B illustrates an exemplary operation of these components. [Figure 2] FIG. 2 is a flow chart of exemplary operations for ensuring cybersecurity policy compliance for multi-part file transmissions. [Figure 3] FIG. 3 is a flowchart of example operations for generating message handling indications for messages intercepted in an application layer session of a multipart file transmission based on determining an action to prevent completion of the multipart file transmission. [Figure 4] FIG. 4 is a flowchart of an example operation for updating a multipart file transmission state data store based on an intercepted message. [Figure 5] FIG. 5 illustrates an exemplary computer system having a protocol-based multipart file transmission regulator. DETAILED DESCRIPTION OF THE INVENTION

[0005] The following description includes exemplary systems, methods, techniques, and program flows to aid in understanding the present disclosure and not to limit the scope of the claims. Well-known instruction instances, protocols, structures, and techniques have not been shown in detail for the sake of brevity.

[0006] overview (Overview)

[0007] Policies may be defined for one or more cybersecurity aspects. Examples include data loss / leakage prevention (DLP), threat detection, and intrusion detection. For cybersecurity policy compliance, files are analyzed to detect malware and / or sensitive information. Performing cybersecurity analysis on multipart file transmissions on network components that exist between sending endpoints (i.e., intermediate network components) may introduce delays that affect the user experience. Furthermore, network components that process network traffic and perform cybersecurity analysis at the application layer have higher computational resource requirements to perform both functions and attempt to reduce the introduced delays. While network components may already inspect and / or analyze packets or datagrams, some cybersecurity analysis analyzes a more comprehensive view of the transmitted data (e.g., the message or document instead of the packet payload carrying part of the message or document). Furthermore, the various protocols implemented by applications for multipart file transmissions increase the complexity of network components to recognize and process traffic with different behaviors due to the different protocols.

[0008] Separating state tracking for different applications' multipart file transmissions from traffic processing at the granularity of individual sessions facilitates cybersecurity enforcement for multipart file transmissions while maintaining the efficiency of inline inspection. The protocol-based multipart file transmission regulator determines a per-session message processing action to prevent completion of the multipart file transmission based on the protocol of the application identified for the session until a cybersecurity analysis can be performed. The protocol-based multipart file transmission regulator then communicates the message processing action to a network component supporting the session. The protocol-based multipart file transmission regulator maintains information and file chunks for active sessions in a data store and uses the data store to determine whether conditions are met for requesting a cybersecurity analysis for the multipart file transmission. Once a cybersecurity analysis verdict is obtained, the protocol-based multipart file transmission regulator provides a verdict or verdict-based instructions to a network component that ensures the multipart file transmission complies with cybersecurity policy. The program logic (hardware and / or software) implementing a "protocol-based multipart file transmission regulator" may be modularized by functionality. For example, determining the relevant protocol and message processing may be implemented as a first program, while tracking the status of the multipart file transmission and submission of files / chunks for analysis may be implemented as a second program.

[0009] Illustrative Description (Example Illustrations)

[0010] 1A-1B are diagrams of an exemplary system for efficiently enforcing cybersecurity compliance of multipart file transmissions. FIG. 1A illustrates exemplary components of the system, and FIG. 1B illustrates exemplary operations of these components. FIG. 1A illustrates a sender endpoint 103 sending a file to a receiver endpoint 105 via a firewall 101 and a network 151 (e.g., the Internet). FIG. 1A also illustrates components 107 of firewall 101 interacting with a protocol-based file transmission regulator 123 to enforce compliance of the multipart file transmission with cybersecurity policies. Protocol-based multipart file transmission regulator 123 uses a data store 125 of protocol information for various protocols of different applications associated with the multipart file transmission and a data store 127 for tracking the status of the multipart file transmission. Protocol-based multipart file transmission regulator 123 (hereinafter, the “regulator”) submits files and / or file chunks to a security analysis service 129 to obtain a verdict.

[0011] The sending endpoint 103 and the receiving endpoint 105 are application layer components of an application that provides a cloud-based solution (e.g., Software as a Service (SaaS), Storage as a Service (STaaS)) for file storage and / or management. The illustrated endpoints 103, 105 represent the client and server components (e.g., threads, processes, modules) of the application and do not represent devices. The illustrated endpoints 103, 105 reside (logically) above other communication layers (e.g., transport layer, network layer) that are not shown to avoid unnecessarily complicating the diagram. The endpoints 103, 105 implement the application's protocol for multipart file transmission 131, which involves multiple application layer sessions. The sending endpoint 103 divides a file into file chunks (“chunks”) and transmits the chunks in different sessions. FIG. 1A shows the multipart file transmission 131, including session 133 in which the final chunk is transmitted. Although Figure 1A shows only data sessions (i.e., sessions transmitting chunks), some multipart file transmissions include a control session that signals the start and completion of a multipart file transmission. In addition, some protocols implemented for multipart file transmissions communicate metadata for file reassembly in the data session, while other protocols communicate reassembly metadata in the control session or in both the control and data sessions.

[0012] The firewall 101 processes incoming traffic 119 (i.e., processes packets) at the network and / or transport layer and forwards the packets as outgoing traffic 121 according to the configuration and policies installed on the firewall 101. In FIG. 1A, a multipart file transmission 131 is part of the traffic 119, 121 according to policy compliance. FIG. 1A illustrates the firewall component 107 as including traffic processing 109, an application identifier 113, a content inspector 115, and a policy engine 117. The traffic processing 109 includes logic (i.e., software and hardware) for forwarding packets according to rules and policies implemented using information from the application identifier 113, the content inspector 115, and the policy engine 117. The application identifier 113 attempts to identify applications accompanying traffic in lower layer sessions (i.e., sessions related to layers below the application layer), and the content inspector 115 inspects traffic content (e.g., datagram payloads or packet payloads) for cybersecurity threats. The policy engine 117 identifies associated policies to apply to the corresponding traffic based on the application identification by the application identifier 113. The policy engine 117 also identifies cybersecurity policies to apply and / or guides the content inspector 115 (e.g., identifying uniform resource locators (URLs) to filter) based on the results of the inspection by the content inspector 115. These components 113, 115, and 117 provide information to the traffic processing 109 for policy compliance.

[0013] To explain an exemplary operation of the system for cybersecurity policy compliance for multi-part file transmission, reference is made to the firewall component 107 and the protocol-based multi-part file transmission regulator 123. FIG. 1B is annotated with a series of letters A-F. Instead of a single stage C, stages C1-C2 are shown due to possible variations in timing relative to each other. Similarly, instead of a single stage D, stages D1-D2 are shown. Each stage represents one or more operations. The stages are shown as an example to aid in understanding the present disclosure and should not be used to limit the scope of the claims. Subject matter falling within the scope of the claims may differ from that illustrated.

[0014] In stage A, the firewall 101 notifies the protocol-based multipart file transmission regulator 123 that an application capable of multipart file transmission has been identified based on analysis by the application identifier 113 and the content inspector 115. For example, the content inspector 115 performs HyperText Transfer Protocol (HTTP) decoding to detect an HTTP message associated with the multipart file transmission after application identification by the application identifier 113. This may involve the content inspector 115 extracting the payload from the lower-layer session to form a message and then decoding the message according to the associated protocol. The firewall 101 communicates the detected message (the “intercepted message”) and the application identifier to the protocol-based multipart file transmission regulator 123.

[0015] In stage B, the protocol-based multipart file transmission regulator 123 selects application-layer protocol information from data store 125 based on the application identifier communicated from firewall 101 and processes the intercepted message. Using the protocol information, the protocol-based multipart file transmission regulator 123 can parse the message and extract metadata identifying the multipart file transmission (e.g., a download or upload identifier) ​​and metadata identifying the application-layer session in which the message was intercepted. Furthermore, the protocol-based multipart file transmission regulator 123 can determine whether the intercepted message carries chunks and extract the chunks. The message metadata can also provide information for file reassembly (e.g., metadata describing a chunk as chunk 2 of 3). The firewall likely observes traffic of different applications that have different protocols for multipart file transmission. The protocol-based multipart file transmission regulator 123 uses a data store 125 (e.g., a configuration file) that contains information about these different application protocols. If the protocol-based multipart file transmission regulator 123 is separate from the firewall 101, this protocol knowledge can be maintained without increasing the resource demands of the firewall 101.

[0016] Stages C1-C2 are stages related to operations performed based on selecting protocol information corresponding to the intercepted message. An implementation can initiate these in any order and execute them simultaneously. In stage C1, the protocol-based multipart file transmission regulator 123 provides a messaging handling indication to prevent completion of the multipart file transmission corresponding to the intercepted message. The message handling indication is based on the intercepted message and protocol information selected based on the application identifier communicated in stage A. The message handling indication indicates whether the intercepted message can be allowed or should be stalled. This indication is protocol and configuration dependent. If completion of the multipart file transmission is prevented by stalling the transmission of the last file chunk or a complete control message, and the intercepted message is the control message or carries the last file chunk, the message handling indication indicates (e.g., using a flag or command) to stall the intercepted message. If the intercepted message does not carry the last file chunk or is not a complete control message, the message processing file directive indicates that the intercepted message (i.e., the packets or datagrams carrying the payload that form the intercepted message) may be sent to the recipient endpoint, or at least sent from firewall 101.

[0017] In stage D1, the firewall 101 updates the session record 111 to stall transmission of the intercepted message if indicated by a message processing instruction from the protocol-based multipart file transmission regulator 123. Stage D1 occurs subsequent to stage C1 because it depends on the message processing instruction, but may occur simultaneously or asynchronously with stages C2 and D2. For the illustrated implementation of the firewall, updating the session record 111 involves the traffic processing component 109 accessing the network and / or transport layer session (“layer 3 / 4 session”) records indicated by the content inspector 115 and setting fields to prevent the firewall 101 from forwarding network traffic for the session corresponding to the selected record. The content inspector 115 (in this exemplary architecture) determines the lower-layer session corresponding to the application-layer session of the intercepted message. In some cases, an application-layer session depends on multiple lower-layer sessions. In these cases, the content inspector 115 maps the application layer session to n lower layer sessions and indicates to the traffic processing component 111 to update the n layer 3 / 4 session records to stall transmission of the intercepted message. If the message processing instructions indicate that the intercepted message should be allowed to pass through the firewall, the associated record in the session records 111 is updated accordingly.

[0018] In stage C2, protocol-based multipart file transmission regulator 123 updates data store 127 with information about the multipart file transmission of the file based on the intercepted message. Protocol-based multipart file transmission regulator 123 maintains data store 127 to track the progress or status of the multipart file transmission. Protocol-based multipart file transmission regulator 123 has visibility into the multipart file transmission as it traverses firewall 101 and possibly other network components. When protocol-based multipart file transmission regulator 123 receives the intercepted message, the visibility is from the intercepted message (i.e., a partial view of the multipart file transmission). By maintaining data store 127 with information about intercepted messages (e.g., chunks, chunk metadata, session metadata) and / or information about the corresponding application-layer session, a comprehensive view of a multipart file transfer can be obtained for correlation with other entries in data store 127 related to the chunks and / or metadata of the intercepted messages. As chunks are extracted from intercepted messages, protocol-based multipart file transfer regulator 123 inserts the chunks into data store 127 indexed or searchable by an identifier identifying the multipart file transfer to facilitate correlation of chunks from different sessions. The multipart file transfer identifier is dependent on the corresponding protocol. For example, protocol-based multipart file transfer regulator 123 can extract the multipart file transfer identifier from the intercepted message and then correlate other messages with the identifier, or construct an identifier from a combination of the file identifier and the application-layer session identifier. As another example, a file identifier combined with an endpoint identifier can be used to identify a multipart file transfer.

[0019] In stage D2, the protocol-based multipart file transmission regulator 123 determines whether a security analysis condition is met for the multipart file transmission based on the information in the data store 127. Stage D2 is performed after the updates in stage C2 but is asynchronous with respect to stage D1. After updating the data store 127, the protocol-based multipart file transmission regulator 123 queries the data store 127 using the multipart file transmission identifier determined from the intercepted message. Using the information in the data store 127, the protocol-based multipart file transmission regulator 123 can correlate chunks and / or metadata from different application layer sessions. For example, the query returns recent updates and any other entries that have the multipart file transmission identifier in common. The conditions for the security analysis depend on the selected protocol information, the configuration of the protocol-based multipart file transmission regulator 123, and / or the customer's policy configuration for the firewall 101. The configuration indicates the granularity for obtaining a security analysis verdict (e.g., file, chunk, or both evaluation), which may vary by firewall, customer, and / or protocol. If configured for chunk, or both file and chunk, granular analysis, the condition for security analysis is chunk availability. For file granular analysis, the condition is the ability to reassemble the file (i.e., availability of chunks to reassemble the file).

[0020] In stage E, protocol-based multipart file transmission regulator 123 obtains a security analysis verdict for the file and / or chunks depending on the results of stage D2. Assuming security analysis service 129 is different from protocol-based multipart file transmission regulator 123, protocol-based multipart file transmission regulator 123 submits the chunks and / or files to security analysis service 129. Security analysis service 129 analyzes the chunks and / or files for malware and / or violations of DLP policies.

[0021] In stage F, the protocol-based multipart file transmission regulator 123 communicates the obtained verdict and / or an instruction to complete the multipart file transmission based on the verdict. The protocol-based multipart file transmission regulator 123 may be configured to provide only a decision and allow further actions to be decided independently of the protocol-based multipart file transmission regulator 123. In this case, the stalled message remains stalled unless other action is taken, for example, by a user. The firewall 101 may be configured to release the stalled traffic based on receipt of a benign verdict. When configured to provide a completion instruction, the protocol-based multipart file transmission regulator 123 communicates an instruction to the firewall 101 that completion of the multipart file transmission should be prevented if the verdict is negative (i.e., a verdict of malicious or non-compliance with cybersecurity policies). For a benign verdict, the protocol-based multipart file transmission regulator 123 is configured to communicate an instruction to the firewall 101 to allow completion of the multipart file transmission. An implementation that communicates only a decision allows the protocol-based multipart file transmission regulator 123 to be agnostic as to how the firewall 101 allows or prevents the completion of a multipart file transmission. An implementation that communicates a completion indication allows flexibility in terms of delegation or division of labor as to how completion or prevention is handled.

[0022] 1A-1B present a limited view of many possible architectural and deployment implementations possible for the disclosed techniques for efficiently securing multi-part file transmissions. Figures 2-3 are flowcharts of more general operations than the examples shown in FIGS. 1A-1B. While the flowcharts are based on the separation of multi-part file transmission regulation from traffic processing and security analysis, the deployment of the corresponding program code may vary (e.g., different devices, virtual machines, etc.).

[0023] 2 is a flowchart of example operations for ensuring cybersecurity policy compliance of multi-part file transmissions. For consistency with FIGS. 1A-1B, the operations are described with reference to a multi-part file transmission regulator as performing the operations.

[0024] In block 203, the multipart file transmission regulator selects protocol information of the identified application for the application layer session corresponding to the intercepted message 201. A network component (e.g., a physical or logical network component) with traffic processing hardware and / or software logic intercepted a message in a session identified as an application layer session associated with an application transmitting files in chunks across multiple application layer sessions. Because the message is associated with a multipart file transmission, the network component intercepts the message to obtain message processing instructions (i.e., inspect or manipulate the message before the receiving endpoint receives it). Because application identification is performed in the network component, in addition to the intercepted message 201, the network component indicates the application identifier. The multipart file transmission regulator uses the application identifier to select the protocol information.

[0025] In block 205, the multipart file transmission regulator determines an action to prevent completion of the multipart file transmission of the file according to the selected protocol information. The protocol information indicates how file chunks are transmitted, how corresponding metadata for reassembly is communicated, whether acknowledgments are required, and how to start and complete the multipart file transmission. The protocol information may also indicate other session management information, such as retries and timeouts. Using this information, the multipart file transmission regulator determines an action to prevent completion of the multipart file transmission. For example, the protocol information may indicate that the action to prevent completion is to stall a control message indicating completion of the multipart file transmission and / or acknowledging receipt of the last file chunk. The prevention action does not necessarily have to be based solely on the protocol information. The multipart file transmission regulator may also refer to customer configuration information or a default policy to determine the prevention action. Using the same example, a preventative action based on protocol information may be to stall the identified control message, but configuration information may specify that at least one file chunk must also be stalled until a security analysis verdict is obtained. Similarly, protocol information may indicate a preventative action to stall the last chunk, but configuration information may specify the percentage of chunks to be stalled. Thus, protocol information indicates a minimum action to prevent completion of a multipart file transmission, while configuration information can extend the preventative action.

[0026] In block 207, the multi-part file transmission regulator generates message processing instructions based on the determined action. If the intercepted message matches the preventive action criteria, the multi-part file transmission regulator generates instructions to stall the intercepted message. A more detailed example of block 207 is provided in Figure 3.

[0027] In block 209, the multipart file transmission regulator updates a data store relating to the multipart file transmission status based on the intercepted message, which may indicate another file chunk of the file transmission, reassembly metadata, a completion acknowledgment, etc. A more detailed example of block 209 is provided in FIG.

[0028] In block 211, the multipart file transmission regulator determines whether conditions are met for submitting a security analysis. The conditions for submitting a security analysis may be defined in configuration by a customer, tenant, etc. For file granularity analysis, the condition is that the multipart file transmission regulator has enough metadata and chunks to reassemble the file for analysis. For file chunk granularity analysis, the condition may be chunk availability, but may also relate to any verdicts of other chunks. For example, a condition may specify that analysis of a chunk can be skipped if another chunk of the same file already has a negative verdict. In some cases, a multipart file transmission may be subject to analysis at both granularities. For example, a malware scan may be at both chunk and file granularity. If the conditions for file granularity analysis are met, the operational flow proceeds to block 213. If the conditions for chunk granularity analysis are met, the operational flow proceeds to block 215. If the conditions are not met, the operational flow ends.

[0029] In block 213, the multipart file transmission regulator reassembles the file from the file chunks in the data store and submits the file for security analysis. Along with the chunks, the data store also hosts metadata that guides the reassembly of the file.

[0030] The multipart file transmission regulator submits the file chunks extracted from the intercepted message for security analysis in block 215. The submission of the file or chunks for security analysis may be via a service request (e.g., an HTTP request), an application programming interface (API) call, etc.

[0031] In block 217, the multipart file transmission regulator obtains a security analysis verdict in response to the submission (block 213 and / or block 215). The dashed lines from blocks 213, 215 through 217 represent asynchronous relationships. The verdict may indicate that malware was detected or that sensitive information was detected in the file or chunk, thus violating a DLP policy.

[0032] In block 219, the multipart file transmission regulator communicates a verdict and / or a multipart file transmission completion instruction based on the verdict to the network component that intercepted message 201. Embodiments may simply communicate the verdict to the network component that intercepted the message and rely on security policies defined at the network component to drive subsequent actions (e.g., notification, quarantine, allow transmission, etc.) based on the verdict. In the case of a negative / malicious verdict, the multipart file transmission does not complete because it is stalled pending security analysis. Embodiments may also communicate an instruction regarding completion of the multipart file transmission based on the verdict. The completion instruction may be to allow the stalled transmission to remain stalled, assuming a negative determination, or to terminate the corresponding application-layer session. In the case of a positive / benign verdict, the completion instruction is to allow the intercepted message to proceed. If multiple messages of a multipart file transfer are stalled, the completion indication may identify the sessions and / or messages that are no longer stalled based on information in a data store that tracks the state of the multipart file transfer.

[0033] 3 is a flowchart of example operations for generating message handling instructions for an intercepted message in an application-layer session of a multi-part file transfer based on determining an action to prevent completion of the multi-part file transfer. The example operations are associated with block 207 of FIG. 2. These example operations precede the determination of an action to prevent completion of the multi-part file transfer. As previously described, the action is determined using protocol information selected based on the application identified for the intercepted message.

[0034] In block 301, the multipart file transmission regulator determines whether metadata of an intercepted message matches action criteria. The action criteria indicate attributes for message matching (i.e., the criteria indicate attributes). Assuming that a control message is stalled to prevent completion of the corresponding multipart file transmission, the criteria may specify the control message type and, possibly, additional attributes indicating completion or acknowledgment of the control message. The action criteria specify that a data message (i.e., a message carrying data chunks) is to be stalled and may allow configuration to specify which chunk to stall, or to stall the last chunk by default, if the last chunk can be identified from metadata extracted from the message. To determine whether the intercepted message matches or satisfies the action criteria, the multipart file transmission regulator evaluates metadata associated with the intercepted message in a data store against the criteria. If the intercepted message matches the criteria, operational flow proceeds to block 303. Otherwise, operational flow proceeds to block 305.

[0035] In block 303, the multipart file transmission regulator instructs the network component that intercepted the message to stall the transmission of the intercepted message. This instruction can be an application layer message, a function call via an API, etc. Accordingly, the network component updates its information (e.g., a forwarding table) to stall the intercepted message. For example, a packet / datagram corresponding to the application layer message is held in the network component's queue until a field is set that allows the packet to be sent.

[0036] In block 305, the multi-part file transmission regulator instructs the network component to allow the intercepted message to be transmitted, avoiding or at least reducing the impact on the user experience while ensuring cybersecurity compliance of the multi-part file transmission.

[0037] 4 is a flowchart of an example operation for updating a data store related to multipart file transfer status based on intercepted messages. The example operation of FIG. 4 is associated with block 209 of FIG. 2. Because the status of a multipart file transfer is based on metadata extracted from messages of different application layer sessions, the multipart file transfer regulator updates the data store and then queries / accesses the data store to determine the status. Thus, each incremental update enables a more comprehensive view of the multipart file transfer.

[0038] In block 401, the multipart file transmission regulator parses the intercepted message according to the selected protocol information to extract metadata associated with the multipart file transmission. Using the selected protocol information, the multipart file transmission regulator can identify message fields in the header and / or body associated with the multipart file transmission. The message may include a field that specifies the start of a chunk. The metadata in the field may indicate the message type (e.g., an acknowledgment or data type) and / or chunk information (e.g., a block identifier). The extracted metadata also identifies the multipart file transmission. This may be explicit. The protocol may require a field in the message (e.g., a download identifier or an upload identifier) ​​to identify the multipart file transmission. The identification of the multipart file transmission may be a combination of metadata. For example, the multipart file transmission may be identified by a file identifier and an endpoint identifier.

[0039] In block 403, the multipart file transmission regulator determines whether the message contains file chunks. If the message identifies the message as a control type or data type message, the multipart file transmission regulator can use this metadata to determine whether the message carries file chunks. If the message contains file chunks, operational flow continues to block 405. If not, operational flow continues to block 407.

[0040] In block 407, the multipart file transmission regulator determines whether the message's metadata indicates the status of the file transmission. Because the message does not carry file chunks, the message is likely a control message. Depending on the protocol, the message may indicate the start or completion of a multipart file transmission. The message may be an acknowledgment of a chunk from the receiver to the sender. If the metadata indicates the status of the multipart file transmission, operational flow proceeds to block 409.

[0041] In block 409, the multipart file transmission regulator updates the data store for the multipart file transmission based on the extracted metadata. The multipart file transmission regulator determines whether an entry for the multipart file transmission already exists by querying the data store with an identifier for the multipart file transmission. If an entry exists, the entry is updated with the metadata. If not, a new entry is created with the extracted metadata associated with the identifier for the multipart file transmission.

[0042] If it is determined in block 403 that the message carries a file chunk, the multipart file transmission regulator updates the data store with the file chunk and metadata for the file chunk that at least identifies the multipart file transmission. Similar to block 409, the multipart file transmission regulator uses an identifier or collection of metadata identifying the multipart file transmission to query the data store and then updates the returned entry or inserts a new entry that includes or references the chunk along with the extracted metadata. The metadata extracted from the intercepted message may identify the chunk relative to other chunks (e.g., chunk 3 of chunk 5, bytes 100-300). To further avoid or reduce latency, the data store may be an in-memory structure (e.g., a Redis data structure store).

[0043] 4 ends after any of blocks 405, 407, and 409. If the metadata does not indicate a multipart file transmission status, the operational flow proceeds to a next set of one or more operations to determine whether to submit the file or chunks for analysis (e.g., block 211 of FIG. 2). Otherwise, after updating the data store (405, 409), the operations proceed to use information in the data store to determine whether to submit the file and / or chunks for analysis.

[0044] Variations

[0045] In some cases, protocols may include retry mechanisms that are triggered while a message is stalled in accordance with the techniques disclosed herein. As one example, an application-layer retry mechanism for multipart file transmission may retransmit stalled chunks in smaller chunks in another application-layer session. Protocol information maintained to coordinate multipart file transmission with cybersecurity policy enforcement may indicate the presence of a retry mechanism, and if an acknowledgment for a chunk (e.g., the last chunk) is not received within a timeout period, the application sender attempts to retransmit the chunk in smaller chunks. Embodiments may be configured to allow a subset of the smaller chunks, stall all of the smaller chunks, or discard all of the smaller chunks. For example, smaller chunks may be discarded, assuming that the chunks from which they were generated are transmitted upon receipt of a benign verdict. Implementations may perform “housekeeping” differently when smaller chunks are detected in a retransmission session. For example, a subset of smaller chunks may be kept instead of larger chunks, or both small chunks and corresponding large chunks may be kept in the traffic queue and released upon receipt of a benign decision, depending on how the protocol handles the scenario.

[0046] The flowcharts are provided to aid in understanding the examples and should not be used to limit the scope of the claims. The flowcharts illustrate example operations that may vary within the scope of the claims. Additional operations may be performed, fewer operations may be performed, operations may be performed in parallel, and operations may be performed in a different order. Although shown as performing after block 207, block 209 may be performed before block 205 or simultaneously with blocks 205 or 207. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may be implemented by program code. The program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable machine or device.

[0047] As will be appreciated, aspects of the present disclosure may be embodied as a system, a method, or program code / instructions stored on one or more machine-readable media. Accordingly, aspects may take the form of hardware, software (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, all of which may be generally referred to herein as a "circuit," "module," or "system." Functionality presented as separate modules / units in the exemplary illustrations may be configured differently according to any of the following: platform (operating system and / or hardware), application ecosystem, interface, programmer preferences, programming language, administrator preferences, etc.

[0048] Any combination of one or more machine-readable media may be utilized. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable storage medium may be, for example, but not limited to, a system, apparatus, or device employing any one or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technologies to store program code. More specific examples (non-exhaustive list) of machine-readable storage media may include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a machine-readable storage medium may be any tangible medium that contains or can store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable storage medium is not a machine-readable signal medium.

[0049] A machine-readable signal medium may include a propagated data signal in which machine-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A machine-readable signal medium is not a machine-readable storage medium and may be any machine-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0050] The program code embodied on the machine-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0051] Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as the Java programming language, C++, etc., dynamic programming languages ​​such as Python, scripting languages ​​such as the Perl programming language or PowerShell scripting language, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may run entirely on a standalone machine, may be executed in a distributed manner across multiple machines, and may be executed on one machine while providing results and / or accepting input on another machine.

[0052] The program code / instructions may also be stored on a machine-readable medium that can instruct a machine to function in a particular manner, such that the instructions stored on the machine-readable medium include instructions that produce an article of manufacture and implement the functionality / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0053] FIG. 5 illustrates an exemplary computer system having a protocol-based multipart file transmission regulator. The computer system includes a processor 501 (possibly including multiple processors, multiple cores, multiple nodes, and / or implementing multithreading, etc.). The computer system includes a memory 507. The memory 507 may be system memory or any one or more of the possible implementations of a machine-readable medium previously described above. The computer system also includes a bus 503 and a network interface 505. The system also includes a protocol-based multipart file transmission regulator 511. The protocol-based multipart file transmission regulator 511 regulates the transmission of messages in an application-layer session of a multipart file transmission to enable analysis of file chunks with minimal impact to the user experience and without increasing resource demands on intermediate network components that process and inspect traffic between endpoints. Any one of the aforementioned functionalities may be implemented partially (or fully) in hardware and / or on the processor 501. For example, functionality may be implemented using an application specific integrated circuit, in logic implemented within processor 501, in a co-processor on a peripheral device or card, etc. Furthermore, an implementation may include fewer or additional components not shown in Figure 5 (e.g., a video card, an audio card, additional network interfaces, peripheral devices, etc.). Processor unit 501 and network interface 505 are coupled to bus 503. Although shown as coupled to bus 503, memory 507 may be coupled to processor 501.

[0054] The use of the phrase "at least one of" preceding a list with the conjunction "and" should not be treated as an exclusive list and should not be construed as a list of categories with one item from each category, unless otherwise specified. A clause reciting "at least one of A, B and C" may be infringed by only one of the listed items, more than one of the listed items, and one or more of the listed items and another unlisted item.

Claims

1. 1. A method comprising: determining, based on an identification of an application for a first session of multiple sessions for a multi-part file transmission of a file, a preventative action to prevent completion of the multi-part file transmission; instructing an intermediate network component to allow transmission of a first message in the first session or to stall transmission based at least in part on the preventative action; obtaining, from the first message, a first chunk of a plurality of chunks constituting the file and first metadata of the first chunk; updating a data store to indicate the first chunk and the first metadata; determining whether a cybersecurity analysis condition is met based on information in the data store corresponding to the file; providing the first chunk or the file for cybersecurity analysis based on a determination that the cybersecurity analysis condition is satisfied; and communicating at least one of the cybersecurity analysis determination and instructions to allow or prevent completion of the multi-part file transmission to the intermediate network component; A method comprising:

2. The method further comprises: parsing at least one of a header and a payload of the first message based on a protocol of the identified application to obtain the first chunk and the first metadata; 2. The method of claim 1, comprising:

3. The step of determining a preventive action includes: determining whether stalling transmission of control messages or file chunks will prevent completion of the multipart file transmission based on a protocol of the identified application; determining the preventive action, the preventive action also being based on configuration information; The method according to claim 1 or 2.

4. The preventive action is: Stalling the transmission of a subset of the chunks that make up the file to a receiving endpoint; Stalling the sending of a control message indicating the completion of the multipart file transmission; stalling the transmission of the acknowledgement message; and stalling the sending of control messages to the receiving endpoint to reassemble the chunks into a file; The method of claim 1 or 2, comprising:

5. The step of communicating instructions to allow completion of the multi-part file transmission includes: is based on the determination indicating that the file is benign or that transmission of the file would not violate a policy; and The step of communicating instructions to prevent completion of the multi-part file transmission includes: based on the determination indicating that the file or the first chunk is malicious or that transmission of the file or the first chunk would violate a policy; the determination is for one of the first chunk and the file; The method of claim 1.

6. The method further comprises: obtaining other chunks of the plurality of chunks and corresponding metadata from other messages in other sessions of the plurality of sessions; updating the data store to indicate the other chunks and corresponding metadata; determining whether the cybersecurity analysis condition is met based on information in the data store corresponding to the file, determining whether the file can be reassembled based on chunks and metadata in the data store; The method of claim 1.

7. A non-transitory machine-readable storage medium having stored thereon program code, the program code comprising a plurality of instructions that, when executed, Track file status for multi-part file submissions to facilitate cybersecurity compliance The instructions for tracking the state of the file include: based on receiving intercepted messages for a session and communications indicating an identified application for the session, updating a data store based on the intercepted messages; determining an action to prevent completion of a multi-part file transmission corresponding to the session based on the identified application; and instructing a network component to stall or allow transmission of the intercepted message based on the determined action; including instructions for determining whether a cybersecurity analysis condition is met based on information in the data store corresponding to the multi-part file transmission based on receipt of the communication indicating the intercepted message; If the cybersecurity analysis condition is met, obtain a cybersecurity analysis verdict for the file of the multipart file transmission or a file chunk extracted from the intercepted message; and communicating the cybersecurity analysis determination and at least one of instructions to allow or prevent completion of the multi-part file transmission to a network component that intercepted the intercepted message; A non-transitory machine-readable storage medium that allows

8. The instructions to communicate the instructions to allow completion of the multi-part file transmission include: instructions for determining that the cybersecurity analysis determination indicates the file as benign or indicates transmission of the file as not violating a cybersecurity policy; The instructions to communicate the instructions to prevent completion of the multi-part file transmission include: determining that the cybersecurity analysis determination indicates the file or file chunk as malicious or indicates transmission of the file or file chunk as violating a policy; The non-transitory machine-readable storage medium of claim 7.

9. The instructions for updating a data store based on the intercepted message include: extracting file chunks from the intercepted message based on a protocol of the identified application; and storing the file chunk in the data store in association with the session, the multipart file transmission corresponding to the session, and the identified application and / or instructions for determining that the intercepted message is a control message based on a protocol of the identified application; and updating the data store to indicate the control message, information identifying the session, information identifying the multi-part file transmission corresponding to the session, and a type of the control message; 9. The non-transitory machine-readable storage medium of claim 7 or 8, comprising instructions for:

10. The instructions for determining an action to prevent completion of the multi-part file transmission corresponding to the session based on the identified application include: selecting the action from a plurality of actions based on the identified application; including instructions for the plurality of actions correspond to a plurality of protocols of different applications; 10. The non-transitory machine-readable storage medium according to any one of claims 7 to 9.

11. The instructions to determine whether the cybersecurity analysis conditions are met include: determining whether the file can be reassembled based on the information in the data store and the file chunks; and the program code further includes instructions for reassembling the file using the file chunks and information in the data store based on a determination that the cybersecurity analysis condition is met.

11. The non-transitory machine-readable storage medium of claim 7.

12. The instructions to determine whether the cybersecurity analysis conditions are met include: determining whether a cybersecurity analysis verdict has been obtained for at least one of a plurality of file chunks comprising the file; Includes instructions for 12. A non-transitory machine-readable storage medium according to any one of claims 7 to 11.

13. An apparatus comprising the non-transitory machine-readable storage medium of any one of claims 7 to 12.

14. A non-transitory machine-readable storage medium having program code stored thereon, the program code comprising a plurality of instructions; The instructions, when executed by a device, cause the device to:

7. Carrying out the method according to any one of claims 1 to 6, Non-transitory machine-readable storage medium.

Images