Implementation

Describes the post configuration steps involved in implementing DSG

The implementation includes RuleSets Configuration, Migration, Testing and Production Rollout.

The configuration of a Ruleset would be subject to the data and how it is exchanged between the systems communicating through DSG. A common SaaS deployment example is followed and additional generic examples, where applicable, are provided.

The process involves the following steps:

  1. Network Setup

    • Domain Name System (DNS)
    • Connectivity
    • Upload or generate SSL Certificates
    • Configure Tunnels
  2. Configuring Ruleset

    • Create a Service under Ruleset
    • Use Learn Mode to find message carrying sensitive data
    • Create a Profile under Service and define rules to intercept the message and transform it
  3. Optional: Forwarding logs to external SIEM systems

  4. Rolling Out to Production

    The implementation section will continue to follow the prototypical organization, Biloxi Corp, example, an enterprise that chose to use a SaaS called ffcrm.com. The crm.example.com story is followed to configure Ruleset profile.

Network Setup

As part of setting up the CRM, you must set up domains names and ssl certificates.

Domain Name System

The CRM SaaS selected by Biloxi Corp is accessible through the public domain name www.ffcrm.com. To integrate the gateway in front of the CRM, the consumers need to be directed to the gateway’s load balancer. A public domain like www.ffcrm.com is owned by a third party. Else, the necessary changes could have been made so it gets resolved to address of the gateway’s load balancer. Therefore, a domain name, www.ffcrm.biloxi.com, is used to internally represent the external www.ffcrm.com one. DNS would then be configured such that all sub domain names (i.e. www.ffcrm.biloxi.com or anything.ffcrm.biloxi.com) will always point to the same gateway’s load balancer address.

The public domain name www.ffcrm.com will be accessible to Biloxi Corp users. However, that concern is addressed by preventing them from successfully authenticating with the service should they attempt to bypass the gateway, intentionally or by error.

In a lab or testing environment, one can alternatively modify their local system hosts file to achieve a similar goal. This approach only effects the local machine and does not support wild card configuration, hence each domain name must be specified explicitly.

For example: 2.10.1.53 ffcrm.biloxi.com www.ffcrm.biloxi.com

This part is completed when all SaaS domain names resolve to your gateway’s load balancer IP address.

Network Connectivity

Biloxi Corp is following network segregation best practices using network firewalls. Thus, communication between systems in different parts of the network is strictly controlled.

Depending on where the gateway is installed, some of the firewall’s configuration must be modified so that the gateway cluster is reachable and accessible. The public domain www.ffcrm.com must also be accessible to the gateway cluster.

Administrative web interface and ssh access to ESA and the gateway cluster may require adjusting network firewall settings.

Verify that the network is properly configured to allow users connectivity to the gateway cluster. This can be validated using tools like ping and telnet. In addition, you’ll need to confirm the connectivity between the gateway nodes themselves and the public SaaS system.

SSL Certificates

The load balancer in front of the gateway cluster at Biloxi Corp is equipped with the appropriate SSL Certificate. However, another certificate needs to be generated to secure the connectivity between the load balancer and the gateway cluster. You could generate the certificate elsewhere and add it to the list along with its key using the upload button.

Generate Certificate screen

Configuring Ruleset

This section explains steps to create rules and how the rule trajectory can be tracked with Learn Mode.

Creating a Service under RuleSet

At this point it is not known how sensitive data is exchanged with the CRM application. To find out the details, the Learn mode functionality is used, which is controlled at the Service level. Before you begin creating services, ensure that you read the Best Practices for defining services. For more information about best practices, refer to Best practices

Using the main menu, navigate to Cloud Gateway > 3.3.0.0 {build number} > RuleSet > RuleSet. Click the Add New Service link to create a new service. After giving it an appropriate name and description, the new HTTP Gateway Service with one or more tunnels needs to be associated. Through these tunnels the www.ffcrm.com application network message exchange will be occur. Use the (+) icon next to the Tunnels and Hostnames fields to associate the service with the default_443 tunnel and the internal hostname to external forwarding address mapping.

Create RuleSet screen

The hostname is how DSG identifies which service applies to an incoming message.

The transaction metric logging feature available at the service level provides a detailed metrics of the transactions occuring in DSG. These details can be logged as part of the gateway.log whenever a protect operation HTTP request is made to the DSG. For more information about transaction metrics options, refer to Transaction Metrics logging.

The sample metrics as seen in the log file are as follows:

Transaction Metrics logged

Restart the gateway cluster for this change to take effect.

Trusting Self-Signed Certificates for an Outbound Communication

Learn-mode is used to find the messages carrying sensitive data, examine their structure and design rules to protect it before it is forwarded on to www.ffcrm.com. For TLS-based outbound communications in DSG, it is expected that the server or SaaS uses a certificate that is signed by a trusted certification authority. In some cases, self-signed certificates are used for outbound communications. For such cases, the DSG is required to trust server’s certificate to enable TLS-based outbound communications.

Perform the following steps to trust self-signed certificates in the ESA node.

  1. In the ESA Web UI, navigate to Settings > System > File Upload.

  2. Click Browse to upload the self-signed certificates.

  3. From the ESA CLI Manager, navigate to Administration > OS Console. Ensure that the certificate is in PEM (ASCII BASE64) format. This may be done by inspecting the certificate file using the cat command to verify whether the contents of the certificate are in readable (BASE64 encoded) or in a binary format.

  4. If the contents of the certificate are in binary format (DER), execute the following command to convert the contents to PEM (BASE64 encoding), else proceed to Step 7.

    openssl x509 -inform der -in <certificate name>.cer -out <certificate name>.pem
    
  5. Create a directory opt/protegrity/alliance/config/outbound_certs/ if it does not exist.

  6. Create a file trusted.cer under /opt/protegrity/alliance/config/outbound_certs if it does not exist.

  7. Copy the contents of the Base64 converted certificate (.pem) file to the trusted.cer file.

    cat <certificate name>.pem >> 
    opt/protegrity/alliance/config/outbound_certs/trusted.cer
    

    If you started with a different certificate file extension name that was already ASCII Base64 encoded, then use the same extension name instead of the “.pem” file extension name in the command example above.

  8. In the ESA Web UI, navigate to Cloud Gateway > 3.3.0.0 {build number} > RuleSet.

  9. Select the service to which the certificate is assigned and click Edit.

  10. Add the following option in the Outbound Transport Settings textbox.

    {"ca_certs": "/opt/protegrity/alliance/config/outbound_certs/trusted.cer"}
    
  11. Restart the Cluster by navigating to Cloud Gateway > 3.3.0.0 {build number} > Cluster to replicate certificates to all DSG nodes.

Use Learn Mode to find message carrying sensitive data

When enabled, Learn mode logs all message exchange to host names matching the service configuration. This allows us to consider these messages payload. One learns how it is structured so appropriate rules can be set to transform the relevant parts in it before it is forwarded on.

Let’s first check that Learn mode is functioning properly by verifying that new entries are shown as the www.ffcrm.biloxi.com application is accessed. Navigate the main menu Cloud Gateway > 3.3.0.0 {build number} > RuleSet > Learn Mode. If this is the first time you’re visiting the Learn mode page then chances are it will come up with no data. You can always click the reset ( ) button to purge the learn mode data.

Learn Mode screen Navigating to the www.ffcrm.biloxi.com application home page will generate new entries in the Learn mode page. It is recommended to use a separate window so that going back to the Learn mode page becomes easier.

CRM login screen

Switch back to the Learn page and refresh the list by clicking the refresh ( ) button. New entries will indicate that Learn mode is functioning as expected.

Learn Mode screen

Password Masking

The www.ffcrm.biloxi.com application requires users to authenticate with their username and password before they can use the application. To avoid Learn mode from logging user’s passwords, Service’ Password Masking needs to be configured. The Password Masking configuration comprised of a regex pattern to identify the URL(s), another regex pattern to identify the password in the payload and a masking value which will be replace the password before the message is logged by Learn mode.

To do that, the request message carrying the password needs to be identified when the authentication is submitted. Using a unique value for the password will make it easier to find in Learn mode. No need to use real username and password, instead let’s use testusertest for the username and testpasswordtest for the password.

CRM login screen

Submit the login form, switch to the Learn mode screen and refresh it.

Learn mode after logging to CRM screen

Additional messages now appear in the list. Let’s examine the first entry listed right after submitting the fake credentials by clicking on it. Additional details will appear at the bottom of the page. Click any entry on the left, select the Messages Difference tab on the right to see the message payload and scroll all the way down.

Learn Mode analysis screen

The rules displayed in the Learn mode screen and the payload message difference are stored in a separate file in DSG. The default file size limit for this file is 3MB. If the payloads and rules in your configuration are high in volume, you can configure this file size.

In the ESA CLI Manager, navigate to Administration > OS Console. Edit the webuiConfig.json file in the /opt/protegrity/alliance/config/webinterface directory to add the Learn mode file size parameter as follows:

{
"learnMode": {
"MAX_WORKER_THREADS": 5,
"LEARNMODE_FLOW_DUMP_FILESIZE": 10
}
}

You can now see that the characteristics of the message carrying the authentication password can be the request message Method and URL. It evident that the authentication with www.ffcrm.com is handled by a POST request to /authentication URI . Thepassword is carried in this message body as a value for the parameter name authentication%5Bpassword%5D . This is URI/www-form encoding for authentication[password].

In some cases, you may need to repeat this test several times to confirm the consistency of the URL, parameter names, etc.

With these details, adjust the service configuration with the details that were found to mask the authentication password or any other data is not required by learn mode to log in the clear. Both the pattern and the resource are regular expressions so let’s use /authentication$ for the resource and (?<=(\bauthentication%5Bpassword%5D=))(.+?)(?=($|&)) for the pattern.

Create Rules screen

Save the changes and restart the cluster for these changes to take effect. You can do that from the Cloud Gateway > 3.3.0.0 {build number} > Cluster page, Monitoring tab.

Restart Cluster screen

Test the change made to the service settings by repeating the authentication attempt as done before. Again, no need to use real credentials, as this step is to ensure the password gets masked in Learn mode.

Learn Mode analysis screen

Note that resetting the Learn mode list makes it easier to find the messages you are looking for in a smaller set of message.

Protecting Sensitive Data

Data protection is achieved by finding the target data in a message and transforming it from its clear state. Then, protect and return it depending on the flow direction of the message. In the www.ffcrm.com application the account names need to be protected So, the gateway will be configured to protect account names in messages transmitting it from user’s browser to the application backend. The gateway will also be configured to unprotect when it is consumed by transforming it in message payloads transmitted from the application backend back to user’s browser.

Following the Protegrity methodology, the discovery phase will uncover all the sensitive data entry points in our target application. One obvious entry point is the page in the application where users can create new accounts. Navigate www.ffcrm.biloxi.com to where new accounts and purge the Learn mode list before creating a new testing account. A sample TestAccount123 is unique enough name to easily find in Learn mode.

Create Account in CRM screen

Switching back to Learn mode page, the message posed with the account name TestAccount123 that was created can be found.

Learn mode analysis screen

Learn mode is showing that DSG sees this information sent as a value to the account[name] parameter in the POST request message body to /accounts URI. The message body is encoded using URL Encoding which is again why account[name] is displayed as account%5Bname%5D.

The details to create a set of rules under Ruleset to extract the posted account name and protect it using Protegrity Data Protection transformation is available. Create a profile under the existing service and call it Account Name.

Create Rules screen

Now create a new rule which will extract the body of the create account message. This rule will look for a POST HTTP Request message with URI matching the regular expression /accounts$.

Create Rule screen

Under the Create Account Message rule, let’s add another rule to extract the value of the parameter which carries the account name found earlier that this parameter name is account[name].

Create Rule screen

Last the account name needs to be protected using a Protegrity Data Protection Transformation rule. This rule requires us to specify and configure how to protect the data. Data Element is a value defined in data security policies managed by Security Officers using Protegrity Enterprise Security Administrator (ESA), which represents data security characteristics like encryption or tokenization. Our security officer had provided us with a data element name PTY_ACCOUNT_NAME which was created for protecting account names in Biloxi corp.

The alliance user is an OS user and is responsible for managing DSG processes. Ensure that you do not add this user as a policy user.

In addition to the data protection, an encoding codec with unique prefix and suffix will be used. The reason for it is so that the protected data will be easy to find by looking for data which begins and ends with the specified prefix and suffix. The ability to find it easily comes handy when the data is consumed and a set of rules must be created to remove the protection. Instead of creating a rule for every message that might carry it, we can scan every message coming back from www.ffcrm.biloxi.com and unprotect every protected data we find corresponding to our prefix and suffix.

Create Rule screen

Restart the gateway cluster and test the new set of rules that was created by creating a new account name TestAccount456.

The expected result is that the new account name will appear protected (encrypted/tokenized and encoded) as oppose to the same way it was entered.

View protected text screen

Lastly, the data protection applied on Account Names needs to be reversed. This allows the authorized Biloxi users consuming this information through www.ffcrm.biloxi.com to see it in clear.

The prefix and suffix will help searching the protected account names in every payload coming back from the application. Therefore, a generic rule for textual payloads can be created. This will look for protected account names and unprotect them such that users will get the HTML payload with the account name in the clear.

The top level branch in this case will target a HTML Response message.

Create Rule screen

In the extracted HTML Response message body, we will look for the protected account names by searching for values matching a regex pattern comprised of our prefix and suffix.

Create Rule screen

The leaf rule of this branch will unprotect the extracted protected account names found in the HTML response payload.

Create Rule screen

Restart the gateway cluster and test the new rules branch created by revisiting the page where TestAccount456 account name appeared protected earlier. A simple refresh of the web page may not be enough as local caching may be used by the browser. Clearing cache, local storage and session information may be required.

View unprotected text screen

Other payload types such as JSON or XML may be used by the application therefore additional generic unprotect rules for these payload types may be required.

Forwarding logs to SIEM systems

You can forward all ESA and gateway logs to an external Security Information and Event Management (SIEM) system, such as Splunk or AWS Cloudwatch.

Forwarding logs to an external SIEM

If you plan to forward all ESA and gateway logs to an external SIEM system, configure the alliance.conf file.

To forward logs to an SIEM system:

  1. In the ESA Web UI, navigate to Settings > System.

  2. Navigate to the Cloud Gateway > 3.3.0.0 {build number} > Settings area.

  3. Click Edit to edit the alliance.conf file.

  4. You can either send all logs to the SIEM system or just the gateway logs.

    1. To send gateway or DSG logs using TCP, add the following rule to the file.

      *.* @@(<IP_ADDRESS> or <HOSTNAME>):<PORT>
      
    2. To send gateway or DSG logs using TCP, add the following rule to the file.

      :msg, contains, "PCPG:" @@(<IP_ADDRESS> or <HOSTNAME>):<PORT>
      

    Ensure that the rule is the first entry in the alliance.conf file. The configurations must be made in ESA. After you deploy the configuration, ensure that the rsyslog service is restarted on each DSG node. If you are using UDP protocol instead of TCP protocol, the rules to be defined are as follows:

    1. To send gateway or DSG logs using UDP, add the following rule to the file.
      *.* @(<IP_ADDRESS> or <HOSTNAME>):<PORT>
    2. To send gateway or DSG logs using UDP, add the following rule to the file.
      :msg, contains, "PCPG:" @(<IP_ADDRESS> or <HOSTNAME>):<PORT>

The following file is a sample alliance.conf file that shows the SIEM configurations.

Alliance.conf file configurations

Forwarding logs to AWS CloudWatch

The AWS CloudWatch must be configured with each DSG node in the cluster to forward the logs from an DSG appliance. After the AWS CloudWatch is configured with a DSG node, you must add the path of the required DSG appliance log files to the appliance.conf file in the appliance. For more information about AWS CloudWatch, refer to AWS Cloudwatch

Rolling Out to Production

Following the Protegrity methodology, production rollout requires deploying DSG with all the necessary rules to protect and unprotect sensitive data. You also need to prevent users/applications bypassing DSG to avoid sensitive data in the clear from reaching the target application directly. Lastly, migrate any historical data that may already exist in the target system.

After Ruleset is created and tested in sandbox or testing environment, back up and export the entire configuration. Then, import and restore it on the production DSG cluster. Addresses, certificates and data elements names may be different from a non-production system which may require some modification to it which applies to production environment only. Before going live it is recommended to test and verify the Ruleset configuration for all sensitive data in scope of the workflow mapped during discovery phase. After a successful testing of the workflows, temporarily bypass DSG to confirm that all sensitive data resided protected on the application backend side. No backend instance of the target sensitive data exists in the clear.

Target application may still be accessible directly, especially when the target application is a public SaaS. For example, after production rollout, Biloxi users may still attempt to access www.ffcrm.com directly. The risk is not in these users seeing protected data as much as it is in them submitting data which otherwise would have been protected by DSG before reaching the application backend. There are several ways to prevent that and may not even be a challenging factor when the target application is owned by the same organization implementing DSG. If the application is external, i.e. SaaS, controlling the authentication can be used to solve this problem.

Authentication may be offered by SaaS using SAML or by owning the authentication process themselves. Most organization would prefer Single Sign On (SSO) using SAML which DSG can be configured to proxy or resign, essentially establishing a trust between DSG and the SaaS. If SAML is not an available option, DSG can be configured to treat username/password as sensitive data as well. This means that users will be known to the SaaS as their protected username and password. An attempt to bypass DSG in such case will result the same as it would for users who are not known to the application at all.

It is not uncommon to introduce data protection to a system already in use. In such cases, it is likely that data designated for protection has already been added to the system in the clear. Historical data migration is the process of replacing the sensitive data from its clear state to a protected state. Applications may offer different ways of achieving this goal normally by exporting the data, transforming it and importing it back into the system. DSG REST API can be used to perform the transformation which will require a Ruleset to be configured for the exported payload format.

Homegrown and third party application changes all the time. Hence, it is highly recommended to maintain a testing environment for future Ruleset or other configuration modification that may be needed.