Guide

Data Compliance: End Users and Least Privilege

When will IT and security teams realize that putting the responsibility of data compliance and security on end users will never succeed?

This is part of a series on data compliance.

Table of Contents

Stop Blaming the End Users

The Economist magazine recently wrote an article called, “The Secrets of a Ransomware Negotiator.” The overall story was about an organization that was a victim of a ransomware attack and called a professional negotiator to help. It is a fascinating article on dealing with data breaches, but it also highlights several aspects of how breaches happen.

First off, data compliance needs to go back to the basics as highlighted by this quote:

Breaches almost always come down to a stupid mistake made by a lazy or gullible human being. No one wants to turn on multifactor authentication. Everyone clicks on suspicious links. Executives neglect to hire enough IT people. Passwords are kept in spreadsheets. It's not that these gangs are advanced. It's that we're sitting ducks.

As if to put an exclamation point on this, in the massive Snowflake breaches that recently happened, Snowflake blamed their customers for using weak passwords, being victims of social engineering and info stealing malware, and not implementing two-factor authentication¹.

People simply want to get their jobs done. They are accountants, lawyers, support teams, factory workers, engineers, human resources and more. They don’t sit around thinking about computer security and it is laughable to think that the annual training video is going to change that.

Lessons Learned

Back to the Economist article, the breached organization had a security operations center (SOC) monitoring their network. (Both were kept anonymous for this article.) The SOC had noticed a user attempting to login “About a thousand times in one day.” The SOC sent the company an email that was ignored. It turned out that the user no longer worked at the company and had administrator access.

Let’s look at three aspects of this case and how data compliance is broken:

In sending the email, the SOC did their part, so it is the IT team’s fault, right? It may be easy to blame the company IT team for not investigating something that seems so obvious in hindsight. However, the thing that is never known in these cases is, how many emails like this does the SOC send? If the SOC is overwhelming the IT team with false positives, then the SOC is not helping and might as well not exist. If they alert on everything, then they alert on nothing. However, if the SOC has a pretty good record of only sending important alerts, the breach is the company IT team's fault. It is also unknown if the SOC and IT teams were properly staffed. What is known is that if this alert had been properly investigated, the story could have ended here. The immediate response could have been to block the attacker IP address and the next response could have been to shut down the account.

The old account brings us to the next aspect. Every data privacy and security standard from PCI DSS to HIPAA to GDPR to NIST talks about providing access based on the idea of “least privilege,” or only providing access to the data they need and nothing more.

The administrator account that belonged to an ex-employee is a violation of the second pillar of data compliance. The first pillar is identifying the sensitive data that needs to be protected. The second is ensuring access controls that enforce least privilege. Clearly, an ex-employee should not have any access to any company data, let alone administrator-level access. Given how important identity access management (IAM) is, it is astonishing how many organizations have no idea how many accounts they have across their IT infrastructure and what access they provide. Hydden is a company that is taking this challenge head-on. Hydden’s continuous discovery platform provides 100% visibility into every identity, account, and privilege across an organization’s infrastructure. This includes Active Directory, Okta, LDAP and cloud IAM to name a few. Those human identities are mapped to the accounts and the corresponding privileges in a single tool so that auditing for over-privilege is easy. Importantly for this case, when the employee left, it would be easy to find all of their accounts and shut them down. Furthermore, it shouldn’t only be employees leaving the company that triggers an audit. Employees moving roles within the company should trigger a re-evaluation of what access they need. Additionally, all access should be audited periodically to prevent the usual growth of privileges as people’s work shifts even in the same roles.

The third aspect of the breach continues with least privilege but asks, “Why should the administrator have access to the data at all?” Today, database and cloud administrators have access to virtually everything and nobody fails an audit for it. The technology simply hasn’t been available to make this possible because the administrators need to have access to the databases to do their jobs and by default get access to the data itself. This is one of the most glaring failures of data compliance today.

Beyond the administrators, applications and their users should be held to the least privilege as well. This includes fine-grained access control down to the digits in many cases. For example, PCI DSS requirement 3.4.1 says,

PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.

The BIN is the first 6 digits of a credit card number and is used to identify the card provider (Visa, Master Card, etc.) and issuing bank (Chase, Capital One, etc.). Some people need access to the BIN for payment routing, some people need access to the last four digits, often support teams for identifying customers, and only a very few need access to the entire credit card number for processing the payment.

Baffle uses encryption as the last best access control. With Baffle, sensitive data is encrypted outside the database, blocking database and cloud administrators from seeing the data, but having no effect on them being able to do their jobs. Even if the data is stolen right out of the database, GDPR and all state privacy laws provide that stolen encrypted data is not a reportable offense and not subject to fines²^,³. At the same time, without code changes, applications can be provided with fine-grained access controls to finally implement least privilege as it was intended.

Conclusion

The breach in the article could have been stopped at several different points. The recognition that they were under attack, shutting down the old administrator account, and not giving the administrator access in the first place were all points that could have prevented this breach. The security world has long promoted the idea of “defense-in-depth” because any one access control could fail. However, end user selected passwords and optional MFA are not cutting it.

Data compliance must stop being a once-a-year box to check. This is the approach of most organizations today and it is failing. Data compliance requires continual investment and a cultural shift in who is responsible for data protection. The end users will never care enough to be effective, so it is up to the security and IT teams to implement the tools required to take responsibility for themselves.