Dynamic Configuration over Programming (CoP)

Ruleset execution can be segregated into Static CoP and Dynamic CoP. In some cases, the payload type and structure is predictable and known. Rulesets for such payloads and processing of data is defined using Static CoP. A user who defines Rulesets using static CoP must be authorized and have permissions to access DSG nodes.

Organizations may be divided into disparate systems or applications. Each system user may send custom payloads on-the-fly to the DSG nodes with little scope for predictability. Providing users with access to DSG nodes for defining Rulesets is risky. In such situations, you can use Dynamic CoP for protection. You must send rules for extraction and transformation as part of a request header along with the data for protection in request message body.

While creating Rulesets for Dynamic CoP, use the Profile Reference rule for data transformation instead of the Transform rule. The security benefits of using Profile Reference rule are higher than the Transform rule. The reason is that the requests can be triggered out of the secure network perimeter of an organization.

Dynamic CoP provides the following advantages:

• Flexibility to send custom requests based on the payload at hand. Prior customization to configuring the ruleset is not needed.
• Restrict or configure the allowed actions that users can send in the request header.

The following figure illustrates how Static CoP RuleSets are combined with Dynamic CoP Rulesets as part of a given REST API or Gateway transaction:

1. The Static CoP Administrator creates the tunnel configurations and Ruleset for the Static CoP rule execution. This static rule forms the base for the Dynamic rule to follow. Based on the URI defined in both the Static CoP rule and Dynamic CoP rule, the entire Ruleset structure is executed when a request is received.
2. The REST API or gateway clients can be application developers of multiple applications in an organization. They may want to protect their data on-the-fly. The developers will create aDynamic CoP structure based on the allowed list of action types and payloads that they are allowed to send as request header.
3. The Dynamic CoP structure provides an outline of how the request header must be constructed.
4. When the request is sent, the header hooks to the Dynamic Injection action type that is part of the Ruleset structure. The Ruleset executes successfully and protected data is sent as a response.

Dynamic CoP structure

Based on the type of Ruleset execution to be achieved, Dynamic CoP can either be implemented with ToT or without ToT.

The following structure explains Ruleset structure when Dynamic CoP is implemented without ToT.

The following structure explains Ruleset structure when Dynamic CoP is implemented with ToT.

In the Figure, the profileName is the profile reference to the profile that the ToT structure follows. Ensure that you understand the Ruleset structure/hierarchy at the DSG node before configuring the Dynamic CoP with ToT rule. Refer to Dynamic rule and Dynamic rule injection.

Use case implemented using Static CoP

The following image explains how the use case would be implemented if static CoP is used.

The individual steps are described as following.

• Step 1 – This step extracts the body of the HTTP request message. The extracted body content will be the entire JSON document in our example. The extracted output of this Rule will be fed to all its children sequentially. In this example, there is only one child of this extraction rule which is step 2.

• Step 2 – This step parses the JSON input as a text document. This is done such that a regular expression can be evaluated to find sensitive data in the document. This step will yield person name strings “Joe Smith” and “Alice Miller” to this child rule. In this example, there is only one child of this extraction rule which is step 3.

• Step 3 – This step splits the extracted data from the previous rule into words. Step number 2 above yielded all person names in the document as strings and this rule in step 3 will split those strings into names . The names can then be protected word by word. This will be done by running a simple REGEX on the input. Each word “Joe”, “Smith”, “Alice”, will be fed into children rule nodes of this rule one by one. In this use case, there is only one child to this rule, which is step 4.

• Step 4– This step does the actual data protection. Since this rule is a transformation node - a leaf node without any children - the rule will return resulting ciphertext or token to the parent.

At the end of Step 4, the RuleSet recursion stack will unwind. Each branch Rule node will reverse its previous action such that the overall data can be returned to its original format. Going back in the reverse direction, Step 4 will return tokens to Step 3 which will concatenate them together into a string. Step 2 will substitute the strings yielded from Step 3 into the original JSON document in place of the original plaintext strings. Step 1 that was responsible for extracting the body of the HTTP request will replace what has been extracted with the modified JSON document. A layer of platform logic outside the RuleSet tree execution will create an HTTP response message. This message will convey the modified JSON document back to the client.

Use case implemented using Dynamic CoP

The following image explains how the use case would be implemented if dynamic CoP is used.

Among the 4 steps described in implementing Static CoP, steps 2 and 3 are the ones that dictate the real business logic. The steps may change on a request-by-request basis. Step 1 defines extraction of HTTP request message body, which is standard in any REST API request processing. Step 2 defines how sensitive data is extracted from input JSON message. Step 3 defines how a string is split into words for word-by-word protection. Step 4 defines the data protection parameters.

The logic for step 4 can either be injected through Dynamic CoP or used through Static CoP using the profile references. The protection rule is statically configured in the system and can be referenced from step 3’s Dynamic CoP JSON rule. Users may choose to use statically configured protection rules. Profile references can be used for an added layer of security controls and governance.

In the example, step 4’s logic will be injected through Dynamic CoP. It shows how to convey data element name and policy user’s identity through Dynamic CoP.

Dynamic CoP Ruleset Configurations

The Dynamic CoP JSON uses the same JSON structure as the Static CoP JSON. The only difference is that Dynamic CoP JSON is dynamically injected. To start off with our Dynamic CoP JSON, parts of the corresponding Static CoP JSON have been copied. Dynamic CoP JSON can be created programmatically. Also, one can use canned JSON template strings and substitute the variable values in it on a request-by-request basis.

The RuleSet JSON fragment for steps 2, 3 and 4 is shown in the following figure. This JSON will be delivered as-is in an HTTP header. It is configured as “X-Protegrity-DCoP-Rules” in our example. DSG will extract this configured header name and inject its value while executing the RuleSet tree.

The following figure shows the skeletal Static CoP RuleSet configuration in ESA WebUI for enabling Dynamic CoP.

The following figure shows how the Dynamic CoP rules are conveyed to DSG in an HTTP header field and the JSON response output in the Postman tool.

The JSON response output is the same in both our Static and Dynamic CoP examples.

• ←Previous
• Next→

Last modified January 21, 2025