A software engine for abstracting security controls in one-way transfer systems.

Abstract

The examples in this disclosure illustrate a system and method for implementing a software-based security abstraction engine in a one-way transport (OWT) system. In the examples, data is received at a first device in the OWT system. A first set of policies is identified based on a data flow identifier associated with the data transport. A policy engine associated with the first set of policies applies the first set of policies to the data to create a digital signature. The digital signature is evaluated by the security abstraction engine to determine whether the set of digital signatures is valid. If the digital signature is determined to be valid, a provenance digital signature of the data is created and a second set of policies is applied to the data. The data is then transmitted to a second device or destination in the OWT system based on the data flow identifier.

Description

Background Art

[0001]

[0001] Many computing environments implement dedicated hardware components that provide security and policy enforcement for data transfer and data storage activities. Often, such hardware components have a significant adverse impact on the scalability of the computing environment due to the cost of the hardware components, the time required to procure the hardware components, and the difficulty of configuring and physically installing the hardware components.

[0002]

[0002] In view of these and other general considerations, the aspects disclosed herein have been devised. Further, although relatively specific problems may be discussed, it should be understood that these examples should not be limited to solving the particular problems identified in the background or elsewhere in this disclosure.

Summary of the Invention

Means for Solving the Problems

[0003]

[0003] An example of the present disclosure illustrates a system and method for implementing a software-based security abstraction engine in a one-way transport (OWT) system. In the example, data to be transported through the OWT system is received by a first device in the OWT system. A first set of policies to be applied to the data during data transport is identified based on a data flow identifier associated with the data transport. A policy engine associated with the first set of policies applies the first set of policies to the data to create a set of digital signatures. The set of digital signatures is evaluated by the security abstraction engine to determine whether the set of digital signatures is valid. In response to determining that the set of digital signatures is valid, the security abstraction engine creates a provenance digital signature of the data. The security abstraction engine also applies a second set of policies to the data. After the second set of policies has been applied to the data, the data is transmitted to a second device or destination in the OWT system based on the data flow identifier.

[0004]

[0004] This summary is provided to introduce in a simplified form a set of concepts that will be further described in the following detailed description. This summary is not intended to identify any major or essential features of the claims, nor is it intended to be used to limit the scope of the claims. Additional aspects, features, and / or advantages of the examples are partially described in the following description, partially revealed from the description, or may be known by the practice of this disclosure.

[0005] Brief explanation of the drawing

[0005] An example is given with respect to the following drawings. [Brief explanation of the drawing]

[0006] [Figure 1]

[0006] An example of a system for implementing a software-based security abstraction engine to be implemented within the OWT system is shown. [Figure 2A]

[0007] This specification provides an example of a routing table for facilitating data transfer using the software-based security abstraction engine described herein. [Figure 2B]

[0007] An example of a routing table for facilitating data transfer using the software-based security abstraction engine described herein is shown. [Figure 3]

[0008] This document presents an example of how to implement a software-based security abstraction engine. [Figure 4]

[0009] This block diagram shows an example of a physical component of a computing device for implementing aspects of this disclosure. [Figure 5]

[0010] This is a simplified block diagram of an example of a distributed computing system for implementing the aspects of this disclosure. [Modes for carrying out the invention]

[0007] Detailed explanation

[0011] Many computing environments and software systems employ dedicated hardware components used to provide data security and policy enforcement for data being transferred or stored. Policy enforcement refers to the process of managing data, devices, and network access and functionality according to one or more policies, which define the conditions under which such access and functionality are permitted. Often, such hardware components negatively impact the scalability of computing environments and software systems due to the cost of the hardware components, the time required to procure them (e.g., ordering and receiving them), the difficulty of configuring the software for the hardware components, and the difficulty of physically installing the hardware components.

[0008]

[0012] One example of the negative impact such hardware components have on scalability is demonstrated in one-way forwarding (OWT) systems. An OWT system refers to a computing system where one or more endpoints are data diodes configured to ensure that data packets can only be forwarded in one direction through the computing system. Often, OWT systems are used to protect networks or endpoints from outbound data transmission, malicious inbound data transmission (e.g., viruses and malware), and cyberattacks. As an example, an OWT system facilitates data transfer between computing environments with the same or different security levels (e.g., high security or low security), where at least one computing environment is unreliable to another. For example, a first computing environment that is highly reliable to the devices of the first computing environment and / or to the devices of one or more other computing environments may receive data from a second computing environment that is considered unreliable by the first computing environment.

[0009]

[0013] In this example, a highly trusted environment refers to a system or network where devices, applications, and users are considered trustworthy, and security measures are in place to establish and maintain that trust. In this type of environment, devices, software, and the devices and / or parties involved, such as users, often adhere to authenticated, approved, and / or established security policies and best practices. Highly trusted environments typically have strict access controls, encryption, and monitoring to ensure that trust is maintained and minimize the risk of unauthorized access, data breaches, or other security incidents. Devices within a highly trusted environment may be authorized to access or be accessed by other devices based on security techniques implemented by the highly trusted environment (e.g., unique encryption keys, secrets, or other cryptographic techniques). For example, communications transmitted by a highly trusted environment may be considered trustworthy by other computing environments or devices based on the fact that the highly trusted environment (and its devices) are included in an allow list (e.g., a list of approved devices and / or computing environments). Alternatively, communications transmitted by a highly trusted environment may be considered trustworthy based on passwords or credentials provided with the communications. In some cases, devices in a highly reliable environment do not require authentication to access or be accessed by other devices. A highly reliable environment generally does not expose the security techniques it implements to other computing environments that it might consider unreliable or unreliable.

[0010]

[0014] In contrast, a low-trust or untrusted environment refers to a system or network where devices, applications, and / or users are implicitly untrusted or at high risk of unauthorized access or malicious activity. A low-trust or untrusted environment may have limited or no security measures in place, or may include or be connected to one or more external or unmanaged devices. Alternatively, a low-trust or untrusted environment may also refer to an environment where devices are not considered protected or trusted by other devices within and / or outside such an environment. Because security techniques implemented by a high-trust environment are not exposed to a low-trust or untrusted environment, a low-trust or untrusted environment may not be able to access or communicate with a high-trust environment without performing various authorization and / or authentication steps that are not required by devices in the high-trust environment. For example, an OWT system may span or include multiple computing environments separated by one or more boundaries between computing environments with different levels of trust and / or security.

[0011]

[0015] The data diode in an OWT system ensures unidirectional data packet transfer through the implementation of hardware and / or software components. In one example, the data diode includes a dedicated transmission network interface card (NIC). The dedicated transmission NIC transmits data to the endpoint, but cannot receive data from the endpoint because the receive pin on the dedicated transmission NIC's network controller chip is physically disconnected. The dedicated transmission NIC may also include firmware that keeps the dedicated transmission NIC's link state always "up" (e.g., enabled and / or active). In another example, the data diode implements a standard (e.g., general-purpose) NIC and a Y-splitter cable. The Y-splitter separates the data transmission signals so that the first cable of the Y-splitter connects to the receiving device and the second cable of the Y-splitter returns to the transmission device to establish a Layer 1 link state. In yet another example, the data diode implements one or more rewritable gate array (FPGA) devices to ensure unidirectional data flow.

[0012]

[0016] In this example, a data diode transmits received data to a dedicated policy enforcer or a device coupled to a dedicated policy enforcer. The dedicated policy enforcer applies one or more policies to the data being transmitted within the OWT system. If the policies are successfully applied to the data, the dedicated policy enforcer allows the data to continue being transmitted through the OWT system. However, if one or more policies are not successfully applied to the data, the dedicated policy enforcer prevents the data from being transferred through the OWT system. In most cases, a dedicated policy enforcer is an expensive hardware device hardwired to the data diode and / or one or more other devices within the OWT system. Therefore, if a dedicated policy enforcer needs to be replaced or added to the OWT system, a considerable amount of manual intervention is required to physically install and / or replace the dedicated policy enforcer. Such manual intervention is often time-consuming, prone to human error, and can result in service interruptions and data security breaches.

[0013]

[0017] This disclosure provides an alternative solution to using the dedicated hardware components described above for policy enforcement. Embodiments of this disclosure describe systems and methods for implementing a software-based security abstraction engine for policy enforcement. In embodiments, a first device in an OWT system receives data (e.g., file or streaming data) transmitted through the OWT system to a destination endpoint as part of a data transfer. The data is associated with a data identifier assigned per data (e.g., per file or per data stream) to uniquely identify the data and / or indicate the type of data. The data transfer is associated with a data flow identifier used to identify a first set of one or more policies applied to the data during the data transfer. Identifying a first set of policies may involve accessing a data structure (e.g., a data table, data array, or data mapping) that stores correlations between individual data flow identifiers, sets of policies, and / or source identifiers (e.g., identifiers of the first device, components of the first device, or source endpoints that provided data to the first device). In the example, each set of policies is associated with a use case for the data transfer. The use case describes a user's purpose or a specific scenario regarding the data transfer. For example, a first use case for transmitting data to a first recipient may be associated with a first policy, while a second use case for transmitting data to a second recipient may be associated with a second policy. Each policy in the first set of policies includes or represents one or more operations performed on data during data transfer. Examples of policies in the first set of policies include an antivirus scan policy, a watchword detection policy, a data hashing policy, a digital signature policy, and file type checking and routing policies.

[0014]

[0018] A policy engine associated with a first set of policies is identified based on a data flow identifier and / or the first set of policies. For example, the data structures discussed above can also identify the policy engine used to execute each set of policies. A policy engine refers to a software component that enforces rules or policies relating to access and functionality of data, device resources, and network resources. An identified policy engine can be selected from a set of multiple policy engines. Each policy engine within a set of policy engines may be configured differently and may be used to apply policies for different use cases. After selecting a policy engine, the identified policy engine applies the first set of policies to the data. In some examples, applying the first set of policies involves creating a digital signature for each operation successfully performed as part of the first set of policies. For example, a security mechanism such as a hardware security module (HSM) can be used to generate cryptographic keys applied to operations (or the results of operations) associated with the set of policies and to create digital signatures. The results may be a transformation or modification of the data, the output of an operation, or an indication (e.g., a numerical or text label) of whether the operation was successful. In some cases, if any of the policies in the first set of policies are not successfully applied to the data, the policy engine terminates the data transfer.

[0015]

[0019] The security abstraction engine provides data and digital signatures. In the example, the security abstraction engine is a software engine implemented as a service to facilitate secure and highly reliable data transfer across the data boundaries of an OWT system. The security abstraction engine is deployable at cloud scale, hardware-independent, and abstracts customer-specific implementations of security controls. The security abstraction engine provides a highly reliable initial codebase that can be configured to meet the needs of individual customers. The security abstraction engine also enforces one-way data flow using software-defined networking that is inaccessible to customers or third parties. In the example, the security abstraction engine evaluates digital signatures to determine if they are valid (e.g., to establish the provenance of a file). This determination may involve comparing the attributes of the digital signature to the expected attributes of the digital signature. For example, the security abstraction engine may use a policy definition to compare the number of digital signatures received, the version of the digital signatures received, and / or the digital signatures received themselves to the corresponding attribute values ​​expected for digital signatures created by executing a particular set of policies.

[0016]

[0020] If the security abstraction engine determines that at least one of the digital signatures is invalid, the security abstraction engine may terminate the data transfer. Alternatively, the security abstraction engine may attempt corrective actions, such as executing a policy or operation, removing a portion of the data from the data transfer, retransmitting the data, or providing a notification to the correction component of the OWT system that one or more digital signatures are invalid. However, if the security abstraction engine determines that the digital signatures are valid, the security abstraction engine creates a provenance digital signature for the data and verifies that the first set of policies has been successfully applied to the data. The security abstraction engine further applies a second set of one or more policies to the data. The second set of policies is selected based on the file type or the content of the data. In some examples, the second set of policies is regulated based on one or more regulatory bodies (e.g., government agencies or industry agencies). Examples of policies in the second set of policies include code verification policies, content sanitization policies, schema verification policies, and video transcoding policies. In at least one example, a provenance digital signature is created for the data after a second set of policies has been applied to the data.

[0017]

[0021] After a second set of policies is applied to the data, a second device or destination endpoint within the OWT system intended to receive the data is identified. Identifying the second device or destination endpoint may involve accessing a data structure that stores the correlation between individual data flow identifiers and destination identifiers (e.g., identifiers for the customer, device, or process receiving the data). The data is then transmitted to the second device or destination endpoint to complete the data transfer (or as part of the data transfer).

[0018]

[0022] In this way, the Disclosure provides several technical advantages and improvements over past solutions that use dedicated hardware components for policy enforcement. These technical advantages and improvements include, among other things, providing a software-based cloud-scaled service that abstracts the policy enforcement of dedicated hardware components and implements functions to ensure one-way data flow; verifying that the policy enforcement provided by the software-based cloud-scaled service meets or exceeds the policy enforcement requirements or standards of the dedicated hardware components used for policy enforcement; providing a consistent user experience through the use of a highly reliable and configurable initial codebase; and ensuring data security of data transferred and / or stored using the OWT system.

[0019]

[0023] Figure 1 illustrates a system for implementing a software-based security abstraction engine. As presented, system 100 is a combination of interdependent components that interact to form an integrated whole. The components of system 100 may be hardware or software components (e.g., application programming interfaces (APIs), modules, runtime libraries) implemented on and / or executed by the hardware components of system 100. In one example, the components of system 100 are distributed across multiple processing units or computing systems.

[0020]

[0024] In FIG. 1, system 100 represents an OWT system for transmitting data between different computing environments. System 100 includes computing environments 102, 104, and 106, and service environment 116. In an example, computing environments 102, 104, and 106 are implemented by a cloud computing environment or another type of distributed computing environment, and are subject to one or more distributed computing models / services (e.g., Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Function as a Service (FaaS)). In some examples, service environment 116 is implemented locally in one or more of computing environments 102, 104, and 106. For example, one or more computing devices within computing environments 102, 104, and / or 106 may each include a separate instance of service environment 116. In other examples, service environment 116 is implemented separately from one or more of computing environments 102, 104, and 106. For example, service environment 116 may be implemented by a cloud computing environment that is remotely accessible by computing environments 102, 104, and / or 106 via a network such as a Private Area Network (PAN), Local Area Network (LAN), or Wide Area Network (WAN).

[0021]

[0025] Figure 1 depicts a specific combination of computing environment and equipment, but the size and structure of the equipment and computing environment described herein can vary and may include additional or fewer components than those shown in Figure 1. Furthermore, while the examples in Figure 1 and subsequent drawings are described in the context of file transfers between OWT systems and computing environments where at least one computing environment is considered unreliable by another computing environment, these examples are equally applicable to non-OWT systems and other types of data transfers between computing environments of various (or the same) types, trust levels, and security levels. For example, these examples are applicable to data transfers between computing environments where equipment running in one or more computing environments is trusted by equipment running in other computing environments (e.g., the computing environments are highly trustworthy of each other). Furthermore, these examples are equally applicable to data transfers between components of a single device. For example, a security abstraction engine may be implemented on a single device having containers with different policies and access privileges (e.g., software data structures for storing data and data objects) to ensure that network traffic received by a first container is inaccessible by a second container considered unreliable by the first container.

[0022]

[0026] With respect to Figure 1, computing environment 102 represents a low-reliability computing environment in which the devices running within computing environment 102 are not trusted by the devices running within computing environment 104 or 106. In such an example, computing environment 102 may be physically separated from computing environments 104 and 106, such that computing environment 102 is in a first physical location (e.g., a region, building, or room) and computing environments 104 or 106 are in a different second physical location. Alternatively, computing environment 102 and computing environments 104 and / or 106 may share the same physical location.

[0023]

[0027] The computing environment 102 includes a computing device 108. Examples of the computing device 108 include data diode and server devices such as web servers, file servers, application servers, and database servers. The computing device 108 receives input data such as a file 110 from a user or a computing device within the computing environment 102 or accessible to the computing environment 102. The file 110 includes one or more types of data (such as audio data, touch data, text-based data, gesture data, and / or image data) and may be associated with a data identifier that uniquely identifies the file 110 and / or indicates the file type of the file 110. In some examples, the file 110 is received as part of a data transfer request to transmit the file 110 to a destination endpoint via the system 100. In other examples, the file 110 is obtained as part of a code deployment request. For example, the file 100 may include source code and may be obtained from a source code repository (such as a low-trust or low-security computing environment) with the intention of deploying the compiled source code within a secure computing environment (a high-trust or high-security computing environment). In at least one example, the computing device 108 performs one or more processing steps on the file 110, such as file segmentation (e.g., splitting the file 110 into one or more data chunks and corresponding data segments), metadata insertion (e.g., inserting sequence identification information into the data chunks and data segments), and data error correction (e.g., applying forward error correction techniques to the data chunks and data segments).

[0024]

[0028] The computer 108 transmits file 110 (and / or data associated with file 110) to the computing environment 104. In this example, computing environment 104 represents a highly reliable computing environment that considers computing environment 102 to be unreliable. Computing environment 104 includes computer 112. An example of computer 112 includes the device described above with respect to computer 108. In some examples, computer 112 is located in close proximity to computer 108 (e.g., in the same building or room). For example, computer 112 and computer 108 may be located in the same room of a data center, such that computer 108 is located in a first data rack (e.g., a server rack or data cabinet) and computer 112 is located in a second data rack or on a different shelf in the first data rack. In such an example, computer 112 and computer 112 may be directly connected via a point-to-point cable. In other examples, computer 112 is located remotely from computer 108 (e.g., in a different building or room).

[0025]

[0029] In Figure 1, computer 112 receives file 110 from computer 108. In response to receiving file 110, computer 112 can access the service environment 116. Alternatively, computer 108 can access the service environment 116 in response to receiving file 110, or in response to processing steps performed by computer 108. In this example, the service environment 116 provides access to various computing services and resources (e.g., applications, devices, storage, processing power, networking, analytics, intelligence). In Figure 1, the service environment 116 includes a routing table 118, a policy engine 120, a security abstraction engine 122, and a routing table 124.

[0026]

[0030] The routing table 118 is a data structure that contains correlation information for data transferred using system 100. In the example, the correlation information includes a data flow identifier, a source identifier, and / or a set of policies (or instructions thereof). For example, Figure 2A shows an example of a routing table 200 that includes columns for data flow ID 202, source ID 204, policy ID 206, and rows 208, 210, 212, and 214. The data flow ID 202 contains a data flow identifier that represents a specific data transfer use case for file 110 and is assigned to each data transfer submitted to system 100. The source ID 204 contains a source identifier for the source endpoint (e.g., a customer, device, or process that submitted the data transfer request). In some examples, policy ID 206 contains a policy identifier for a set of policies, as indicated by rows 208, 210, 212, and 214. The policy identifier is used (e.g., in a lookup table) to identify a set of operations that should be applied to file 110. For example, the first operation could be an executable command to apply an antivirus scan using a first antivirus engine, the second operation could be an executable command to apply an antivirus scan using a second antivirus engine, and the third operation could be an executable command to perform watchword detection. In another example, policy ID 206 contains a set of operations corresponding to a set of policies applied to file 110. In yet another example, policy ID 206 contains an identifier for the policy engine used to apply the set of policies to file 110. The policy engine indicated by the identifier may be configured to perform a default set of operations or to apply a default set of policies.

[0027]

[0031] Returning to Figure 1, the data flow identifier for file 110 is used to look up the routing table 118 for a first set of policies to apply to file 110. In this example, the first set of policies includes policies for running an antivirus scan engine, watchwork detection, hashing data and files, generating digital signatures, checking and routing file types (e.g., routing file 110 to specific policy enforcement components related to file types), data sanitization (e.g., splitting, removing, and reassembling data content), and data journaling (e.g., data retention). The first set of policies may also include additional policies for evaluating, auditing, and / or managing data in other ways. The first set of policies can be defined at various granularity levels, such as cloud level, customer subscription level, or data flow level. For example, the selection of an antivirus scanner may be a function of the source environment of file 110, the destination environment of file 110, a customer profile, or a data transfer use case profile. Once a first set of policies is identified, a policy engine for applying that first set of policies, such as policy engine 120, is identified based on the data flow identifier or the first set of policies. For example, a data structure (e.g., routing table 118 or a separate configuration table) may contain entries corresponding to multiple different policy engines. The data flow identifier or the first set of policies may be used to select an entry in the data structure that correlates the data flow identifier or the first set of policies to policy engine 120. Alternatively, policy engine 120 may be automatically selected and invoked in response to preparing the first set of policies to be executed. For example, a specific policy engine used to execute a set of policies may be hardcoded within the policy or one or more operations of the policies. In such an example, multiple policy engines 120 may be used to apply the first set of policies to file 110.

[0028]

[0032] The policy engine 120 is a software engine that applies policies to data transmitted using the system 100. In an example, the policy engine 120 applies a first set of policies to a file 110. Applying the first set of policies involves performing one or more operations on the file 110 related to the first set of policies. Each operation may be a set of executable instructions performed by the policy engine 120 sequentially or in parallel with other operations. As an example, the policy engine 120 may perform a first operation that causes the policy engine 120 to make a call (e.g., a request) to a first antivirus service, which includes a pointer to data on which an antivirus scan is performed. After (or during) the antivirus scan performed by the first antivirus service, the policy engine 120 may perform a second operation that causes the policy engine 120 to make a call to a second antivirus service. In some cases, the policy engine 120 applies additional policies to file 110 or performs additional processing on file 110 based on a data identifier related to file 110 or the file type of file 110. For example, the policy engine 120 may apply a first type of processing or policy to a first type of file 110 (e.g., a Portable Document Format (PDF) file) and a second type of processing or policy to a second type of file 110 (e.g., a Joint Photographic Expert Group (JPEG) file).

[0029]

[0033] In the example, the policy engine 120 creates a digital signature for each operation successfully performed on file 110. Creating a digital signature may involve applying a cryptographic key to the operation or the result of the operation. For example, a cryptographic device or service such as an HSM or a certificate authority can create a public-key-private key pair using public-key cryptography. The private key portion of the public-key-private key pair is provided to the policy engine 120 and can be used by the policy engine 120 to create a digital signature. If a digital signature has been successfully created for each operation associated with the first set of policies, the policy engine 120 provides file 110 and the set of digital signatures associated with the operation to the security abstraction engine 122. For example, the policy engine 120 provides file 110 along with an extensible markup language (XML) manifest containing the set of digital signatures to the security abstraction engine 122. In at least one example, instead of creating a digital signature for each operation performed, the policy engine 120 creates a digital signature for each policy performed or for the entire first set of policies.

[0030]

[0034] The security abstraction engine 122 is a software engine that abstracts security controls and verifies the policies applied to file 110 by the policy engine 120. In the example, the security abstraction engine 122 evaluates the digital signature created by the policy engine 120 and determines whether the digital signature is valid. This evaluation ensures that the operations associated with the first set of policies were performed as expected and that the digital signature was not modified during transport from the policy engine 120. Evaluating a digital signature involves comparing the digital signature (or attributes of the digital signature) to the digital signature (or expected attributes of the digital signature) expected for the first set of policies. For example, a policy definition for the first set of policies may be stored by (or accessible to) the security abstraction engine 122. The policy definition indicates the expected digital signature for each operation performed as part of the first set of policies. Upon receiving the digital signature of file 110, the security abstraction engine 122 compares the digital signature of file 110 to the expected digital signatures enumerated in the policy definition. If the digital signature of file 110 does not match the corresponding digital signature enumerated in the policy definition, the mismatched digital signature of file 110 is determined to be invalid. If one or more digital signatures for file 110 are determined to be invalid, the security abstraction engine 122 may attempt to terminate the transfer of file 110 through system 100 or take corrective action against the data transfer, as described above.

[0031]

[0035] However, if the digital signature of file 110 matches the digital signatures enumerated within the policy definition, the digital signature of file 110 is determined to be verified, and the security abstraction engine 122 creates a proven digital signature for file 110. Creating a proven digital signature may include applying an encryption key to file 110, as discussed above. The proven digital signature confirms that the first set of policies has been successfully applied to file 110. The security abstraction engine 122 appends the proven digital signature to file 110 or associates the proven digital signature with file 110. For example, the proven digital signature can be added to the metadata of file 110, or stored in a data structure that correlates the proven digital signature with file 110.

[0032]

[0036] The security abstraction engine 122 also applies a second set of policies to file 110. In an example, the second set of policies may include policies for code validation (e.g., validation of source code and compiled code), data sanitization, schema validation (e.g., validation of file schemas and data schemas), and video and audio transcoding. In a particular example, the second set of policies may include schema validation policies that describe and validate the structure and content of an XML document. For example, schema validation policies are used to define elements that can be included in an XML document (e.g., simple elements, compound elements, or global elements), attributes (e.g., data that provides characteristics of a particular element), and data types (e.g., Boolean, integer, or string). Schema validation policies cause the system 100 to remove any content not defined by the schema validation policies from the XML document being transmitted. The second set of policies may also include additional policies for evaluating, auditing, and / or otherwise managing data. While certain types of policies have been provided herein as examples of the first set of policies and the second set of policies, these examples may be included in either or both of the first set of policies and the second set of policies.

[0033]

[0037] The security abstraction engine 122 may include various policy enforcement components to implement a second set of policies. Each of these policy enforcement components may represent a different dedicated hardware device used for policy enforcement in a conventional policy enforcement system. For example, the security abstraction engine 122 implements code processing, compound document processing, and video processing functions. The code processing function is assigned to process software artifacts such as software libraries, executable files, and software builds. The code processing function can verify that file 110 is of a specific type (e.g., a software artifact type) and perform additional functions such as compiling source code, verifying code, or generating a digital signature for the file. The compound document processing function is assigned to process compound documents. A compound document refers to a document that contains document objects other than text and / or images (e.g., graphs, tables, macros, and other executable content), such as a PDF document, XML document, presentation document, or spreadsheet document. The compound document processing function performs content standardization, such as removing content (e.g., macros and images) from file 110 and reformatting the content of file 110. The video processing function is assigned to process video data such as video files or video streams. The video processing function processes the video content (for example, by modifying the aspect ratio, frame rate, color, and other attributes of the video content) and transcodes the file 110 using one or more data compression and decompression utilities such as codecs.

[0034]

[0038] Routing table 124 is a data structure that contains routing information for data transferred using system 100. In the example, the routing information includes at least a data flow identifier and a destination identifier. For example, Figure 2B shows an example of routing table 250 that includes columns for data flow ID 252 and destination ID 254, and rows 258, 260, 262, and 264. Data flow ID 252 contains a data flow identifier that represents a specific data transfer use case for file 110 and is assigned to each data transfer submitted to system 100. Destination ID 254 contains a destination identifier for the destination endpoint (e.g., a customer, device, location, or process intended to receive file 110). For example, the destination identifier can identify a container or queue in system 100 to which file 110 should be delivered in order to complete the data transfer request. In some examples, the information in routing tables 200 and 250 (and thus routing tables 118 and 124) may be contained within the same table.

[0035]

[0039] Referring again to Figure 1, the data flow identifier of file 110 is used to look up the routing table 124 to find the destination endpoint of file 110. Once the destination endpoint is identified, file 110 is transmitted to the compute environment 106. In some examples, compute environment 106 represents the highest security compute environment relative to compute environments 102 and 104. In other examples, compute environment 106 represents a compute environment with the same or lower security level as compute environments 102 and / or 104. In Figure 1, compute environment 106 includes data storage 114. Examples of data storage 114 include directly attached storage devices (e.g., hard drives, solid-state drives, and optical disc drives), network-based storage devices (e.g., storage area network (SAN) devices, and network-attached storage (NAS) devices), and other types of memory devices. Data storage 114 receives and stores file 110. In some cases, data storage 114 provides file 110 to a destination endpoint or to another device that facilitates the delivery of file 110 to a destination endpoint, based on a destination identifier stored in routing table 124.

[0036]

[0040] Having described systems that may be employed by embodiments disclosed herein, we now provide methods that may be performed by such systems. Method 300 will be described in the context of system 100 in Figure 1, but the performance of Method 300 is not limited to such examples.

[0037]

[0041] Figure 3 illustrates a method 300 for implementing a software-based security abstraction engine. In this example, the security abstraction engine is implemented within an OWT system that includes multiple computing environments. One or more computing environments may have different trust levels, security levels, or physical locations. For example, in some embodiments, one computing environment is a low-security environment and another is a high-security environment. In other embodiments, one or more computing environments are considered low-trust relative to other computing environments. The OWT system may be configured such that the source endpoints and / or destination endpoints of data transmitted through the OWT are unknown to one or more computing environments.

[0038]

[0042] Method 300 begins with operation 302, in which a file, such as file 110, is received by a first device, such as computing device 108. In the example, the file is received as part of a data request (e.g., a file transfer request or a code expansion request) identified by data flow identifiers such as data flow IDs 202 and 252. The file is associated with a data identifier that may be contained in the file or the file's metadata. In some examples, the first device is located within a first computing environment of an OWT system, such as computing environment 102. The file originates at a source endpoint within the first computing environment or is provided to the first computing environment from an external source endpoint. Examples of external source endpoints include personal computers (PCs), server devices, mobile devices (e.g., smartphones, tablets, laptops, personal digital assistants (PDAs)), wearable devices (e.g., smartwatches, smart eyewear, fitness trackers, smart wear, body-mounted devices, head-mounted displays), game consoles or devices, and Internet of Things (IoT) devices. In at least one example, the source endpoint includes, or has access to, one or more repositories that store source code files and / or executable files. Upon receiving a file, the first device can perform one or more processing steps on the file, such as file segmentation, metadata insertion, and data error correction.

[0039]

[0043] In operation 304, the first device provides a file to a second computing environment of the OWT system, such as computing environment 104. In some examples, the second computing environment is implemented within the first device. For example, a first component or system of the first device may implement the first computing environment, or a second component or system of the first device may implement the second computing environment. In other examples, the second computing environment includes a second device, such as computing device 112. In such examples, the second computing environment may be logically separate from the first computing environment, but the second device may be located in close proximity to the first device. For example, the first and second devices may be located in the same building, the same room, or the same data rack. Alternatively, the second device may be located physically separate from the first device (e.g., in a different region or building).

[0040]

[0044] In operation 306, the second computing environment identifies a first set of policies to apply to a file using the file's data flow identifier. In the example, identifying the first set of policies involves accessing a service environment, such as service environment 116. The service environment may be implemented within the second computing environment or may be accessed remotely from the first and / or second computing environments. The data flow identifier may be used to search data structures within the service environment, such as routing table 118, for the first set of policies correlated with the data flow identifier. The first set of policies may include, for example, policies related to antivirus scanning, watchwork detection, data and file hashing, digital signature generation, file type checking and routing, data sanitization, and data journaling. The first set of policies may be stored in a data structure as a set of one or more operations corresponding to executable instructions. Alternatively, the first set of policies may be represented in a data structure using a policy identifier, such as policy ID 206. The data structure may also correlate a first set of data flow identifiers and / or policies to a source identifier that identifies a source (e.g., device, customer, or process) associated with a file or a data request for a file. For example, a source identifier might indicate a container implemented on a first device to store data and files for a particular customer. This container may be assigned for use in one or more specific use cases, while another container implemented on the first device may be assigned for use in alternative use cases.

[0041]

[0045] In operation 308, a policy engine in the service environment, such as policy engine 120, is selected to apply a first set of policies to a file. In the example, the policy engine is selected based on the first set of policies and / or the file's data flow identifier. For example, the above data structure can also correlate a specific policy engine with a specific set of policies and / or a data flow identifier. Alternatively, executing a policy or operation can invoke one or more policy engines. For example, an executable instruction corresponding to an operation can define the policy engine used to execute a policy or a set of operations associated with a policy. Thus, multiple policy engines can be used to apply a first set of policies to a file.

[0042]

[0046] In operation 310, the policy engine applies a first set of policies to a file. Applying the first set of policies involves performing one or more operations on the file that are associated with the first set of policies. In the example, each operation may be digitally signed beforehand to ensure that the operations are not corrupted or improperly modified. In some examples, the policy engine applies additional or alternative policies or performs additional operations based on the file's data identifier or file type. After performing the first set of policies, the policy engine creates a digital signature for each operation successfully performed on the file. The digital signature provides assurance that each operation was performed successfully and / or in the expected manner. Creating a digital signature may involve applying a cryptographic key to an operation or the result of an operation. For example, the private key portion of a public-private key pair may be applied to the set of executable instructions corresponding to an operation. Alternatively, the public key portion may be applied to the file or to the portion of the file modified by applying the first set of policies to the file. Digital signatures of operations associated with a first set of policies can be applied to the file content (e.g., body), to the file metadata, included in another document or file (e.g., a manifest or similar document), or stored in a data structure (e.g., a table or data flow log). In some examples, if at least one policy in the first set of policies is not successfully applied to the file, the policy engine stops or aborts the transfer of the file.

[0043]

[0047] In operation 312, a security abstraction engine in the service environment, such as security abstraction engine 122, evaluates the digital signature. In the example, the files and digital signatures associated with a first set of policies are provided to the security abstraction engine by the policy engine. The security abstraction engine evaluates the digital signature created by the policy engine and verifies that the policy engine successfully and / or executed the first set of policies in the expected manner. The security abstraction engine also evaluates the digital signature to verify that it has not been modified during transport from the policy engine. In the example, evaluating the file's digital signature involves comparing the file's digital signature (or attributes of the digital signature) to the digital signature (or expected attributes of the digital signature) expected for the first set of policies. For example, the security abstraction engine may compare the file's digital signature to a trusted set of digital signatures previously generated by applying the first set of policies to one or more other files. If the security abstraction engine determines that the digital signature is valid (for example, if it determines that the first set of policies was successfully applied to the file and the digital signature has not been modified), it generates a provenance digital signature for the file. Provenance digital signatures can be applied to files as discussed above, or they can be stored in another location.

[0044]

[0048] In operation 314, the security abstraction engine applies a second set of policies to the file. In the example, the security abstraction engine includes one or more policy enforcement components (e.g., a software engine, a function, or other processing logic) for applying policies to a file based on its file type, other file attributes, and / or file content. For example, the security abstraction engine may include a code processing component, a composite document processing component, and a video processing component. The code processing component can process software artifact files, the composite document processing component can process composite document files, and the video processing component can process video and / or audio files. In the example, the file is provided to the relevant policy enforcement component based on the file type or content of the file. For example, a policy engine configured to perform file type checking and routing can route the file to the corresponding policy enforcement component of the security abstraction engine based on the file type determined during a file type checking operation for the first set of policies. Alternatively, upon receiving a file, the security abstraction engine can determine the file type of the file and provide the file to the policy enforcement component used to process the determined file type. As a concrete example, a file determined to be a source code file is provided to the code processing component.

[0045]

[0049] Upon receiving a file, the policy enforcement component applies a second set of policies to the file. This second set of policies may include policies related to code compilation and verification, content sanitization, schema verification, and audio / video transcoding, for example. For instance, the second set of policies may include a schema verification policy that describes and verifies the structure and content of an XML document. Such a schema verification policy causes the OWT system to remove any content not defined by the schema verification policy from the XML document being transmitted. For example, any elements, attributes, and / or data types not defined by the schema verification policy are removed from the XML file. In at least one example, a provenance digital signature is generated for the file after the second set of policies has been applied to it.

[0046]

[0050] In operation 316, the file is provided to a destination endpoint, such as data storage 114, based on the file's data flow identifier. In the example, the data flow identifier may be used to look up a data structure, such as routing table 124, to find the file's destination endpoint. For example, the data structure can correlate the data flow identifier with a destination identifier, such as destination ID 254. The destination identifier can identify a destination endpoint (e.g., a container or storage location) for storing data and files for a particular customer. In some examples, the destination endpoint is located within a third computing environment of the OWT system, such as computing environment 106. In other examples, the third computing device is implemented within the first or second device. The destination endpoint can function as an aggregation point for one or more components or devices inside or outside the OWT system. In at least one example, the destination endpoint is the computing environment where the file is deployed. For example, a source code file may be built, compiled, and digitally signed as it is transferred through the OWT system (or as part of the file being transferred). The compiled file can be securely deployed and executed within the computing environment based on the digital signature.

[0047]

[0051] Figures 4-5 and related descriptions provide an overview of various operating environments in which embodiments of this disclosure may be put into practice. However, the devices and systems illustrated and discussed in relation to Figures 4-5 are for illustrative purposes only, and as should be understood, a vast number of computing device configurations may be used to put into practice the embodiments of the disclosure described herein.

[0048]

[0052] Figure 4 is a block diagram showing the physical components (e.g., hardware) of a computing device 400 in which embodiments of this disclosure may be put into practice. The computing device components described below may be suitable for the above computing device and system. In a basic configuration, the computing device 400 includes at least one processing system 402 and a system memory 404. Depending on the configuration and type of the computing device, the system memory 404 may include volatile storage (e.g., random access memory (RAM)), non-volatile storage (e.g., read-only memory (ROM)), flash memory, or any combination of such memories.

[0049]

[0053] The system memory 404 includes one or more program modules 406 suitable for running an operating system 405 and one or more software applications 420 such as one or more components supported by the system described herein. The operating system 405 may be suitable, for example, for controlling the operation of a computing device 400.

[0050]

[0054] Furthermore, embodiments of this disclosure may be implemented with graphics libraries, other operating systems, or any other application programs, and are not limited to any particular application or system. This basic configuration is shown in Figure 4 by the components within the dashed line 408. The computing device 400 may have additional features or functions. For example, the computing device 400 may also include additional (removable and / or non-removable) data storage devices, such as magnetic disks or optical disks. Such additional storage is shown in Figure 4 by removable storage device 407 and non-removable storage device 410.

[0051]

[0055] As described above, several program modules and data files can be stored in system memory 404. While running on a processing system 402 including one or more processors, a program module 406 (e.g., application 420) can execute processes including those described herein. Other program modules that may be used in accordance with the embodiments of this disclosure may include email and contact applications, document processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-assisted application programs, and the like.

[0052]

[0056] Furthermore, embodiments of the present disclosure can be implemented in electrical circuits including discrete electronic elements, packaged or integrated electronic chips including logic gates, circuits utilizing microprocessors, or on a single chip including electronic elements or a microprocessor. For example, embodiments of the present disclosure can be implemented by a system-on-a-chip (SOC), in which each or many of the components shown in Figure 4 may be integrated on a single integrated circuit. Such an SOC device may include one or more processing systems / units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or "burned into") a chip substrate as a single integrated circuit. When operating by an SOC, the functions described herein with respect to the client's ability to switch protocols may be operated by application-specific logic integrated with other components of the computing device 400 on a single integrated circuit (chip). Embodiments of the present disclosure can also be implemented using other techniques capable of performing logical operations such as AND, OR, and NOT, including but not limited to mechanical, optical, fluid, and quantum technologies. In addition, embodiments of the present disclosure can be implemented in a general-purpose computer or in any other circuit or system.

[0053]

[0057] The computing device 400 may also have one or more input devices 412, such as a keyboard, mouse, pen, voice or audio input device, touch or swipe input device, etc. It may also include output devices 414, such as a display, speaker, printer, etc. The devices described above are examples, and other devices may be used. The computing device 400 may include one or more communication connections 416 that enable communication with other computing devices 450. Suitable examples of communication connections 416 include radio frequency (RF) transmitters, receivers, and / or transceiver circuits, universal serial buses (USB), parallel and / or serial ports.

[0054]

[0058] As used herein, the term computer-readable medium may include computer storage medium. Computer storage medium may include volatile and non-volatile removable and non-removable media implemented by any method or technique for storing information such as computer-readable instructions, data structures, or program modules. System memory 404, removable storage device 407, and non-removable storage device 410 are all examples of computer storage medium (e.g., memory storage). Computer storage medium includes RAM, ROM, electrically erasable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital multipurpose disk (DVD) or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or any other manufactured products that can be used to store information and are accessible by the computer 400. Any such computer storage medium may be part of the computer 400. Computer storage medium does not include carrier waves or other propagating or modulated data signals.

[0055]

[0059] Communication media may be embodied by computer-readable instructions, data structures, program modules, or other data within modulated data signals such as carrier waves or other transport mechanisms, and include any information distribution medium. The term “modulated data signal” may refer to a signal in which one or more characteristics are set or modified in a manner that encodes information within the signal. For example, communication media may include wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media.

[0056]

[0060] Figure 5 shows one aspect of the architecture of a system for processing data received by a computing system from a remote source such as a personal computer 504, a tablet computer 506, or a mobile computer 508, as described above. The content displayed on the server device 502 may be stored by different communication channels or other types of storage. For example, various documents may be stored using a directory service 522, a web portal 524, a mailbox service 526, an instant messaging store 528, or a social networking site 530.

[0057]

[0061] The input evaluation service 520 may be employed by a client communicating with the server device 502, and / or may be employed by the server device 502. The server device 502 can provide data to and receive data from client computing devices such as a personal computer 504, a tablet computing device 506, and / or a mobile computing device 508 (e.g., a smartphone) via the network 515. As an example, the above-described computer system may be embodied by a personal computer 504, a tablet computing device 506, and / or a mobile computing device 508 (e.g., a smartphone). In addition to receiving graphical data that can be used for pre-processing in a graphics generation system or post-processing in a receiving computing system, any of these embodiments of the computing device can obtain content from the store 516.

[0058]

[0062] As can be understood from this disclosure, an example of the technology discussed herein is a system comprising a processing system and a memory coupled to the processing system, which includes computer executable instructions that perform at runtime operations including receiving a file in a first computing environment within a one-way transfer (OWT) system, the file being associated with a first data flow identifier, identifying a first set of policies to apply to the file based on the first data flow identifier, applying the first set of policies to the file using a policy engine, the policy engine creating and applying a set of digital signatures for the first set of policies, evaluating the set of digital signatures using a security abstraction engine, applying a second set of policies to the file using a security abstraction engine, and transmitting the file to a destination based on the first data flow identifier.

[0059]

[0063] In another example, the technique discussed herein is a method that includes receiving a file in a first device in a first computing environment, the file being associated with a data flow identifier; providing the file to a second device in a second computing environment that has access to a service environment; identifying in the service environment a first set of policies to apply to the file based on the data flow identifier; applying the first set of policies to the file by a policy engine in the service environment; creating a set of digital signatures for the first set of policies by the policy engine; determining whether the set of digital signatures is valid by evaluating the set of digital signatures using a security abstraction engine in the service environment; applying a second set of policies to the file by the security abstraction engine in response to determining that the set of digital signatures is valid; and transmitting the file to a third computing environment based on the data flow identifier.

[0060]

[0064] In another example, the technology discussed herein relates to a device including a processing system and memory, which includes computer executable instructions that perform operations at runtime, including receiving data associated with a dataflow identifier indicating a use case for the data; applying a first set of policies to the data by a policy engine based on the dataflow identifier; creating a set of digital signatures for the first set of policies; evaluating the set of digital signatures using a security abstraction engine; applying a second set of policies to the data by a security abstraction engine based on the type of data; and providing the data to a destination based on the dataflow identifier.

[0061]

[0065] Aspects of this disclosure are described above, for example, with respect to block diagrams and / or operational diagrams of methods, systems, and computer program products relating to aspects of this disclosure. The functions / actions shown within a block may be performed in a different order than those shown in any flowchart. Depending on the functions / actions involved, for example, two consecutively shown blocks may actually be executed almost simultaneously, or the blocks may be executed in reverse order.

[0062]

[0066] The descriptions and illustrations of one or more embodiments provided herein are not intended in any way to limit or restrict the scope of the disclosure set forth in the claims. The embodiments, examples, and details provided herein are considered sufficient to transfer ownership and enable others to create and use the best form of the disclosure set forth in the claims. The disclosure set forth in the claims should not be construed as being limited to any embodiments, examples, or details provided herein. Various features (both structural and methodological) are intended to be selectively included or omitted to create embodiments having a particular set of features, whether illustrated and illustrated together or separately. Since the descriptions and illustrations provided herein are provided, a person skilled in the art can devise variations, modifications, and alternative embodiments that do not deviate from the broader scope of the disclosure set forth in the claims and that fall within the spirit of a broader embodiment of the general inventive concept embodied herein.

Claims

1. Processing system (402), A memory connected to the processing system (402), Receiving a file in a first computing environment within a one-way transfer (OWT) system (302), wherein the file is associated with a first data flow identifier, receiving (302), Identifying a first set of policies to apply to the file based on the first data flow identifier (306), Applying a first set of policies to the file using a policy engine (310), wherein the policy engine creates and applies a set of digital signatures to the first set of policies (310), Evaluating the set of digital signatures using a security abstraction engine (312), Applying a second set of policies to the file using the security abstraction engine (314), and (316) Transmitting the file to the destination based on the first data flow identifier. Memory (404) and a computer executable instruction that performs an operation including the operation at runtime. A system (100) including this.

2. The system (100) according to claim 1, wherein the first data flow identifier indicates a use case that describes a user's purpose or a specific scenario.

3. Identifying the first set of the policy (306) Accessing a data structure located within the service environment of the OWT system, wherein the data structure is A second data flow identifier that matches the first data flow identifier, and Correlation between the second data flow identifier and the first set of policies Including access, Searching for the data structure using the first data flow identifier, and Identifying a first set of policies within the data structure based on the match between the first data flow identifier and the second data flow identifier. The system (100) according to claim 1, including the above.

4. Receiving the file in the first computing environment (302) includes receiving the file in a first device within the first computing environment, Identifying the first set of the aforementioned policies The first device provides the file to the second device in the second computing environment of the OWT system (304), and Accessing the service environment by the second device The system (100) according to claim 3, further comprising:

5. The system (100) according to claim 4, wherein the first computing environment is a low-reliability environment in which the devices in the first computing environment are not trusted by the devices in the second computing environment.

6. Applying the first set of policies to the file using the policy engine (310) Identifying the correlation between the policy engine and at least one of the first data flow identifier or the first set of policies, and Selecting the policy engine from a plurality of policy engines based on the correlation (308) The system (100) according to claim 1, including the above.

7. The first set of the aforementioned policy is Antivirus scan policy, and File type checking policy The system (100) according to claim 1, comprising at least the following:

8. Each policy in the first set of policies relates to a set of operations, Creating the set of digital signatures for the first set of policies is Performing each operation within the set of operations on the aforementioned file, and To create a digital signature for each operation that was successfully performed. The system (100) according to claim 1, including the above.

9. Evaluating the set of digital signatures using the security abstraction engine (312) The set of digital signatures is compared with the expected set of digital signatures generated by applying the first set of policies to other files. Determining that the set of digital signatures matches the expected set of digital signatures, The security abstraction engine generates a provenance digital signature from the file. The system (100) according to claim 1, including the above.

10. The system (100) according to claim 1, wherein the security abstraction engine includes at least a first policy enforcement component and a second policy enforcement component, the first policy enforcement component is configured to apply a policy to a first file type, and the second policy enforcement component is configured to apply a policy to a second file type different from the first file type.

11. Applying the second set of the policy to the file (314) Based on the file type of the file, provide the file to the first policy enforcement component or the second policy enforcement component, and The first policy enforcement component or the second policy enforcement component applies the second set of policies to the file. The system (100) according to claim 10, including the system described in claim 10.

12. The first policy enforcement component and the second policy enforcement component are, Code processing component, Compound document processing component, or Video processing component The system (100) according to claim 10.

13. The second set of the aforementioned policy is Code verification policy, Content sanitization policy, Schema validation policy, or Audio / Video Transcoding Policy The system (100) according to claim 1, comprising at least one of the following.

14. Transmitting the aforementioned file to the aforementioned destination (316) Accessing a data structure that includes the correlation between the first data flow identifier and the destination, and Transmitting the file to the destination based on the correlation (316), wherein the destination is located in a different computing environment of the OWT system than the first computing environment (316). The system (100) according to claim 1, including the above.

15. Receiving a file (302) in a first device within a first computing environment, wherein the file is associated with a data flow identifier, receiving (302), Providing the file to a second device in a second computing environment that can access the service environment (304), Identifying a first set of policies to apply to the file based on the data flow identifier within the service environment (306), The policy engine in the service environment applies the first set of policies to the file (310), The policy engine creates a set of digital signatures for the first set of policies. (312) Determining whether the set of digital signatures is valid by evaluating the set of digital signatures using the security abstraction engine within the service environment. In response to determining that the set of digital signatures is valid, the security abstraction engine applies a second set of policies to the file (314), and Transmitting the file to a third computing environment based on the data flow identifier (316) Method (300), including the method (300).

16. The method according to claim 15 (300), wherein the first computing environment, the second computing environment, the third computing environment, and the service environment are part of a one-way forwarding (OWT) system.

17. The method according to claim 15 (300), wherein the second set of policies includes a schema validation policy for XML documents.

18. The method according to claim 17 (300), wherein the schema validation policy defines elements, attributes, and data types that can be included in an XML document.

19. Applying the first set of policies to the aforementioned file (310) As part of the first policy within the first set of policies, execute the first antivirus scanning engine on the file, and As part of a second policy within a first set of the aforementioned policies, execute a second antivirus scanning engine on the file. The method according to claim 15 (300), including the method according to claim 15.

20. Processing system (402), A memory (404) connected to the processing system (402), Receiving the data associated with a data flow identifier that indicates a use case for the data (310), Applying a first set of policies to the data by the policy engine based on the data flow identifier (310), Creating a set of digital signatures for the first set of policies, Evaluating the set of digital signatures using a security abstraction engine (310), Applying a second set of policies to the data by the security abstraction engine based on the type of data (310), and (310) Providing the data to the destination based on the data flow identifier. Memory (404) and a computer executable instruction that performs an operation including the operation at runtime. Apparatus (400), including the apparatus.

Images