Establish Guardrails for Data

How to Use Data Context to Ensure Compliance - Data Security Rules Explained Part 3

Michael Ness
Security Researcher
August 5, 2022

Introduction

This blog post is the third in a four-part series that explains what we've found that works for creating actionable alerts for cloud data security. The first two parts explained the main ingredients - data classification, data context, and the engines behind rules and policies. This blog will address the regulatory compliance use case, specifically Payment Card Industry Data Security Standard (PCI DSS) compliance, and explain how rules and policies combine with data context to detect violations. 

PCI DSS is essentially a checklist to ensure that infrastructure configuration related to the storage of sensitive payment card data follows best practices. Compliant configurations can obviously vary between on-premises and cloud and between different cloud platforms. One example is AWS Config rules that ensure the configuration of the relevant assets are compliant with the standard. 

While the standard has been around since 2008, countless organizations have suffered data breaches due to non-compliance. These include Equifax in 2017 with the exposure of 147 million records, Target in 2013 with the exposure of payment card data of 41 million customers and PII of over 70 million customers, and Warner Brothers Group in 2020 which exposed personal and payment card information.

PCI-DSS Compliance Requires Data Context

The Open Raven Data Security Platform utilizes these config rules via the policy and rules engine which we discussed in part 2 of this series. In doing so the product can also ensure cloud-specific configuration rules comply with different standards. Unlike Cloud Security Posture Management (CSPM) tools, Open Raven provides data context through data discovery and classification in addition to configuration details. With data context, Open Raven combines security posture (config data) with information on sensitive data location and type (asset catalog and data catalog). With this information, SecOps teams can alert on potential violations depending on if sensitive data is in storage. These can be used in combination with configuration based rules to provide more context in an area-specific manner. The perfect example of this is if you are storing US based PII in European data stores or vice versa. Essentially this provides context of what data is stored where and in what region, the idea being you can ensure you are compliant to the data regulations in which the data is stored. Watch E1 of Data Security Questions to learn more about this use case. You can see examples of what the PCI-DSS policy looks like as well as violations from this particular policy.

Screenshot of the Edit a Policy function in Open Raven. On the left is the form with Policy ID, Policy Name, Policy Description and Policy Status. On the right is a list of rules that were added to this policy. This account is read-only so no changes can be made on this screen.
Screenshot of a specific policy violation. This is a medium severity violation. The rule is 'Security Groups allow ingress from 0.0.0.0/0 to port 22.' Users can see violation status, policy, account numbers, and take action (copy a link, copy accounts affected, and copy regions affected). Below is a table titled Assets with Violations. It includes teh asset name, account number, region and Jira ticket information. Account numbers have been redacted.

Using Data Context to Ensure Compliance

Upon linking your cloud provider account within the Open Raven Data Security Platform, all of your assets will be discovered in a continuous manner. This allows the platform to have an idea of what assets exist in your account as well as their configuration. Rules currently exist which identify violations in the configurations of these assets against the required configurations set by specific standards. If any violations are found these are recorded in the platform. All of the rules related to a specific standard can be packaged up into a policy, so you can have a clear idea whether or not you are compliant with any of the policies that exist within the platform and if not, have the details to understand exactly why.

The image below is an example of a policy that checks for region specific financial data storage that is not in the specified region: 

Screenshot of the Edit a Policy function in Open Raven. On the left is the form with Policy ID, Policy Name, Policy Description and Policy Status. On the right is a list of rules that were added to this policy with the option to remove or add more.

Another example of combination rules we have in the platform can be demonstrated by the policy shown below. This policy contains rules that are used for finding various sensitive data types that exist in assets that do not have encryption at rest enabled:

Screenshot of the Edit a Policy function in Open Raven. On the left is the form with Policy ID, Policy Name, Policy Description and Policy Status. On the right is a list of rules that were added to this policy. This account is read-only so no changes can be made on this screen.

You can see what the violations from these policies look like in the context of the platform: 

Screenshot of a specific policy violation. This is a low severity violation. The rule name is 'Canadian Financial Data in Non-Canadian Datastores.' Users can see violation status, policy, account numbers, and take action (copy a link, copy accounts affected, and copy regions affected). Below is a table titled Assets with Violations. It includes the asset name, account number, region and Jira ticket information. Account numbers have been redacted.

Conclusion

These examples precisely illustrate the outcomes that can be achieved when combining both context on the data itself as well as the configuration of the asset. The Open Raven Data Security Platform will alert you of any violations, allowing you to pinpoint data security and compliance risk, apply the appropriate guardrails, prevent incidents, and streamline response.

Don't miss a post

Get stories about data and cloud security, straight to your inbox.