Types of Data Security Risks - Data Security Rules Explained Part 2

This blog post is the second in a four-part series that explains what we've found that works for creating actionable alerts for cloud data security. In part 1, we explained that there is a "recipe" made up of five components for operationalizing data security in the cloud at scale:

1. Data Classification - to identify sensitive data
2. Data Context - to identify the precise conditions that matter for the data itself
3. Rules / Rules Engine - to define what conditions we want to test for by matching data and context, which then in turn create…
4. Alerts - the time-honored security event that we know how to feed into existing workflows & response tooling; more necessary than beloved
5. Policies - to group both rules and alerts together

This blog post will expand on rules and the rules engine and their relation to policies and how they can be used to secure developer secrets. 

Data Security Rules & Policies 

The following points were made clear in the last post that rules are essentially files containing meta-data about the purpose of a specific rule and an operational Postgres query. The Postgres query is what is executed by the rules engine, and if any matches are found against the query they are stored in a violations table against that specific asset with the meta-data about the rule. This links in with what was mentioned in the previous post; you can refer back to look at the specific format of violations within the Open Raven UI. Below, you can see an example of a publicly available Magpie rule:

The question here is, how do rules and policies tie together? Well, as mentioned previously, policies are essentially a collection of rules. Policies, like rules, contain meta-data that infers the policy's purpose, and rather than include Postgres queries, policies contain the file names of rules. The concept here is that policies are interpreted by a policy engine that sends the specified rules to the rules engine alongside the meta-data from the policy. This is just an extra step to what is mentioned above and occurs in the same way, where any matches are stored as violations under that specific rule and appropriate policy. You can see an example of one of our publicly available Magpie policies below:

With a better understanding of both what policies are, their application in the product, and how rules are integrated within them, we can discuss the risks associated with developer secrets and how rules and policies can be used to safeguard them.

Types of data security risks:

There are two main risks associated with developer secrets in the context of data security, and these are: where are they stored and where are they used?

In terms of "where are they stored?" We are talking about the physical storage of secrets. This refers to developer secrets, whether IAM credentials or API keys stored in either S3 buckets or hard-coded into Git repositories. It is important to know where these exist as it is against best practices to hard-code or store them in plain text anywhere. The Open Raven platform can help identify these secrets across both S3 buckets and Git repos by using policies and rules to ensure you have full visibility.

In terms of "where are they used?" We are talking about the physical usage of these secrets, whether this is for application deployment or employee usage. Often in larger organizations, it is hard to track exactly where credentials are used and who by. Therefore it is important to ensure these are rotated correctly and all best practices are in use. The example I will use is IAM access keys. Open Raven can help ensure these are set up using best practices utilizing the rule and policy engine. The rules for these configuration-based detections are available in the open-source Security Rules repo. The first image shown above is the perfect example of this where we can ensure AWS IAM access keys are rotated every 90 days. 

Safeguarding Developer Secrets:

Open Raven can safeguard your developer secrets in both a data-security and configuration sense. The product identifies developer secrets stored in plain text, and these findings are logged against that particular bucket. An example finding from the data scan would be bucket X contains 1x AWS Secret Key, which alone is not what alerts users, but it is, in fact, the policy and rules engines that are responsible. The policies are made up of rules which look for S3 assets that contain specific types of characterized data using the Postgres queries. Matches found within the queries executed through the rules are logged as violations against the particular asset. This is an example of the data security perspective, and although no examples can be shared of these policies and rules involved, as they are not open-source, they can still be actively used within the product. 

Looking at the configuration side of things, policies can be configured with specific rules to ensure that any secrets for cloud access are set up with the best practices enabled. The rules engine executes queries that check the configuration of cloud assets in your account. If any violations of best practices are found within the configurations, these will be logged as violations against that asset under the context of both the rule and policy. The perfect example of such a policy is the aws-iam-best-practices policy that enforces best practices for IAM-related assets.

Let's take a look at one rule from the policy as a more specific example.

The above rule checks the configuration of the root account and ensures that no IAM key is in use for the particular account. This helps to protect your account as it ensures that no root account with the highest level of privilege could be compromised through leaked IAM credentials. If active credentials are present, then it will create a violation for you. This rule and policy exist within the Open Raven Data Security Platform and Magpie, our open-source tool which checks asset configurations.

Summary and Next Up

Open Raven can help you maintain an excellent data-security posture for developer secrets by using policies, rules, and their respective engines. This is by a two-pronged approach which ensures that 1) you are not storing developer secrets in plain text across both Git and S3, and 2) you are configuring developer secrets within your cloud accounts with the best practices in mind. If any of these are not followed, then Open Raven will alert you in the form of viewable violations from the UI within the product.

In the next blog in this series, we'll take a deep dive into compliance rules and policies.