🌀Eli Nesterov

TL;DR:

We often have access to the data we don't even know exist or need. We have unnecessary permissions on too many data objects. We need to change how we deal with data security and apply zero-trust principles to mitigate growing risks to the data. Two unrelated events caught my attention recently. One of them is the recent Robinhood data breach security incident that happened on November 3rd, exposing data of 7M users. Another one I read a few months ago in one of Daniel Miessler's The Unsupervised Learning Newsletter about a Brooklyn woman who destroyed more than 20 GB of data in retaliation for being fired. Interestingly, in their article about the latter case , OODA Loop mentions the importance of offboarding, which would help mitigate the risk, but won't fix the root cause.

So what is common between these two cases that caused my attention? For me, these two cases highlight what we all see every day in our work - we all have access to a vast amount of data with too many permissions. In many cases, we have access to the data we don't even know about or don't need for our day-to-day work.

One may argue that in the Robinhood case, each customer support team member should have access to a lot of sensitive information to help with different customer situations, and I agree with that. The woman from Brooklyn who deleted more than 20GB of financial information should have access and permission to all that data as well.

However, the main concern here is why in both cases, employees could access that many records? To do the work efficiently, they only need access to the data of 10th or 100 customers a day, so the real question is, why do we provide access to millions of records/files instead of a few?

The answer is simple: we don't know which records data users need access to, so we provide everything they need to perform their work, including permissions to delete the data.

What both these cases remind us that we need a shift in the data security model.

We need a shift of paradigm for data security . Data security is not a new and relatively complex topic. On a very high level, there are two main parties involved that want opposite things:

data users need access to all the data to do their work; security and governance organizations want nobody having access to any data (so it is safe); Of course, these are two extremes, and each organization creates a model that would be somewhere in between. Different risk mitigation models, systems, tools, frameworks, and security controls will help move the state left or right. The model organization use is never static and changes over time like in a zero-sum game, making one of the sides happier and efficient but more problematic at the same time for the other.

For instance, when security introduces RBAC(or even ABAC) model to access data, users lose access to some information they used to have (because security thought they didn't need it). To re-gain access data, users open support tickets and eventually get access to the data they need but waste lots of time in the process. The story repeats every time for a new project. Later during the audit security team can realize that way too many people have access to a lot of sensitive data, clean-up access policies are making some data users unhappy again.

It is a very frustrating experience. That is why security organizations do not like to create and update access control policies.

Some products on the market offer a better experience through the mix of RBAC and ABAC (and other *BAC) that some companies call dynamic access control. Unfortunately, these products do not solve the issue when someone with malicious intent is accessing millions of records instead of just a few, so we still will continue to see data security incidents mentioned earlier.

Shifting toward zero-trust data security. I know it sounds pretty buzzwordy, but what if we apply a zero-trust model to data security? Can we use the "never trust, always verify" principle here?

Despite NIST and NCSC having slightly different points of view on building zero-trust architecture, they both agree on per-request access decisions. So the crucial part of implementing zero-trust data security is authenticating and evaluating each data query using additional context.

The lack of additional context is the component we miss today to prevent multiple data security incidents involving a vast amount of data. We use some context information in modern access control systems, but a lot is left behind.

For instance, if, on average, each person from the customer support team only accessing the data of a few hundred customers and we use such data in the context of each data query or request, then exfiltrating the data of millions of users would be unlikely. A similar approach would prevent deleting Gigabytes of data in the context of files (how many files on an average daily person from the department delete?).

Another issue with access policies is that implementing policy changes usually takes a long time. The amount of data that needs to be processed and taken into account every time we introduce any changes is enormous, resulting in mistakes and misconfigurations. We are not very good at it, and the only way to deal with that is through automation. Even NIST recognizes that and working on a draft to use machine learning for access control policy verification.

But should we push it even further and eliminate the need to create and update these policies manually and for me as a data user to request some changes to them?

If I'm a user who needs to request access to each table in each database every time I want to use it and that it takes a long time to approve and implement, there is no way any business will use such a product. Now imagine if you need to do the same for each request or query.

I like the way Joseph Carson defines this:

"Zero trust is all about reducing risk without increasing friction for users." If we are talking about an ideal world zero-trust data security system, it might look like this:

As a data user, I work using data, helping customers, discovering new product insides, or improving machine learning models. I don't need to change any tools or integrate new frameworks or SDK. It just works. If I need access to any new data, I use it without going through the frustrating experience of filing support tickets and then waiting hours or days before continuing my work. Everything is just magically working for me.

As a security, I don't need to write, modify and constantly update access control policies to provide new users access to the data they need. I don't need to set reminders for myself and my team to clean up these permissions and update policies again when data users are done with their work. I am confident that a one-person account compromise wouldn't result in millions of records leaked or files deleted. During the audit, I can quickly demonstrate who has access to what data and why because the number of people accessing the data is minimal.

This list can continue on and on. What would you want to see on that list?

🌀Eli Nesterov

San Jose, California, United States 2K followers 500+ connections

See your mutual connections View mutual connections with 🌀Eli Sign in Welcome back Email or phone Password Show Forgot password? Sign in or New to LinkedIn? Join now or New to LinkedIn? Join now

Experience

SPIRL

-

-

-

-

-

-

-

Honors & Awards

F5 Networks 5-Star Award

F5 Networks

View 🌀Eli’s full profile

Other similar profiles

Evan Gilman

Camille Gaspard

Ryan Hurst

Amir O.

Assaf Rappaport

Daniel Feldman

Luke Deshotels

Canming Jiang

Joe Beda

yogi porla

Timothy Peacock

Tushar Singal

Gourav Nagar

Evan Cox

Ravi Srinivas Ranganathan

Brian Ambielli

Forest Handford

Gokhan Akdugan

Prasad Kavuri

Angela Zhang

Explore collaborative articles

Add new skills with these courses

SSCP Cert Prep: 7 Systems and Application Security

Introduction to AWS Penetration Testing

Penetration Testing Essential Training

San Jose, California, United States

2K followers 500+ connections

View mutual connections with 🌀Eli

Welcome back

Email or phone

Password

Forgot password?

or

New to LinkedIn? Join now

or

New to LinkedIn? Join now