A call for data-first security

Over the past two decades, we’ve seen security become increasingly granular and move deeper into the stack generation after generation – from hardware to network, server, container, and now increasingly to code.

It should be focused on the data. First.

The next frontier in security is data, especially sensitive data. Sensitive data is the data that organizations do not want to see leaked or breached. This includes PHI, PII, PD and financial data. There are real penalties for a breach of sensitive data. Some are tangible, such as GDPR fines (€10 million or 2% of annual turnover), FTC fines (eg. $150 million against Twitter) and legal fees. Then there are intangible costs, such as the loss of customer trust (eg Chegg exposed facts belonging to 40 million users), restructuring pain and worse.

>>Don’t miss our special issue: The CIO Agenda: The Roadmap for IT Leaders in 2023.<

Current data protection technologies embrace exaggerated approaches. Just look at identity management. It is designed to verify who is who. In reality, these approaches contain inevitable points of failure. Once authorized by identity management, users have carte blanche to access important data with minimal restrictions.

What would happen if you made data the center of the security universe?

One of the most precious assets organizations want to protect is data, and massive data breaches and data leaks are all too common. It’s time for a new evolution of cybersecurity: data-first security.

Data is different

First, let’s recognize that data doesn’t exist in a vacuum. If you’ve struggled to understand and comply with GDPR, you know that data is tightly connected to many systems. Data is processed, stored, copied, modified and transferred by and between systems. With every step, the vulnerability potential increases. That’s because the systems associated with these steps are vulnerable, not because the data is.

The basic concept is simple. Stop focusing on each system individually without any knowledge of the data they contain and the links between them. Instead, start with data and then pull the thread. Is sensitive data involved with talkative loggers? Is data shared with unauthorized third parties? Are security checks missing for data stored in S3 buckets? Missing data encryption? The list of potential vulnerabilities is long.

The challenge with data security is that data flows almost infinitely across systems, especially in a cloud-native infrastructure. In an ideal world, we should be able to monitor the data and associated risks and vulnerabilities at any time in any system. In reality, we are far from this.

Data-first security must start in the code. For developers, that means: Shift left. According to GitLab, 57% of security teams have already shifted security to the left or plan to do so this year. Start at the beginning of the journey and secure data as you encrypt.

But the dirty secret of shift-left is that all too often it means organizations are imposing more work on the tech team. For example, they may have them fill out surveys and questionnaires that somehow assume they have expertise in data governance requirements in global economies, local markets, and highly regulated vertical industries. That’s not what developers do.

So a data-first security approach should have three components: 1) It shouldn’t be another security liability; 2) It must understand the property context; 3) It protects against flaws in custom business logic (not every breach involves a bug).

Not another security liability

Security is about mitigating risk. Adding a new tool or supplier goes against this basic principle. We all have SolarWinds in mind, but others pop up daily. Getting a new tool integrated into your production environment is a big ask, not only for the security team, but also for the SRE/Ops team. Discovering data on the production infrastructure means looking at actuals, potential customer data – essentially what we’re trying to protect in the first place. Perhaps the best way to avoid becoming another risk is simply not to access sensitive infrastructures and data.

Since a data-first security approach relies on knowledge of sensitive data, it can be surprising to be able to perform this discovery only from the codebase, especially when we are used to DLP and data security posture management (DSPM) solutions that perform discovery on production data. It’s true that in the codebase we don’t have access to actual data (values), only metadata. But interestingly enough, it is also very accurate to discover sensitive data this way. Indeed, the lack of access to values ​​is compensated by the access to a huge number of contexts, which is essential for classification.

As valuable as traditional shift-left security is, a data-first security approach offers even more value when it comes to not just another risk to the organization.

Ownership context

When it comes to data security and data protection, not everything is black or white. Some risks and vulnerabilities are very easy to identify. Examples include a logger leaking PHI, or a SQL injection exposing PD, but others require some level of discussion to assess the risk and ultimately decide on the best solution. Now we enter the frontier of compliance, which is never far away when we talk about data security.

Why do we store this data? What is the business rationale for sharing this data with this third party? These are questions that organizations will have to answer at some point. Today, these questions are increasingly being addressed by security teams, especially in cloud-native environments. Answering them and identifying the associated risks is nearly impossible without revealing the “ownership.”

By securing data first from a code point of view, we have direct access to massive contextual information – esp when something has been introduced and through whose. DSPM solutions simply cannot provide this context by looking solely at production data archives.

Too often organizations rely on ‘manual review’. They send questionnaires to the entire technical team to understand what sensitive data is processed, why and how. Developers hate these questionnaires and often don’t understand many of the questions. The poor data security results are predictable.

As with most “technical” things, if you’re serious about data security, especially at scale, the most effective approach is to automate tedious tasks with a process that falls into existing workflows with minimal or no friction.

Custom business logic

Since every organization is different, coding practices and policies vary, especially for larger technical teams. We’ve seen many companies adopt application-level encryption, end-to-end encryption, or connect to their data warehouse in very specific ways. Most of these logic flows are extremely difficult to detect outside of code, resulting in a lack of monitoring and introducing security vulnerabilities.

Let’s take Airbnb as an example. It infamous built its own data protection platform. What’s interesting to look at here is the custom logic the company has implemented to encrypt its sensitive data. Instead of relying on a third-party encryption service or library (there are dozens of them), Airbnb built its own, Cypher. This provides libraries in several languages ​​that allow developers to encrypt and decrypt sensitive data on the fly. Detecting this encryption logic, or more importantly the lack of it, on some sensitive data outside the codebase would prove very difficult.

But is code enough?

It makes a lot of sense to start a data-first security journey from code, especially since many of the insights found there are not accessible anywhere else (although it is true that some information may be missing and only found at the infrastructure or production level) .

Reconciling information between code and production is extremely difficult, especially with data assets flowing everywhere. Airbnb shows how complex it can be. The good news is that with the shift to infrastructure as code (IaC), we can make the connections at the code level and avoid painful reconciliation.

Given the challenges associated with security and data, any security solution will need to become at least “data-aware” and possibly “data-first” at whatever layer of the stack they are at. We are already seeing Cloud Security Posture Management (CSPM) solutions mixing with DSPM, but will it be enough?

Guillaume Montard is co-founder and CEO of Bearer.