Achieve Zero Trust data protection using Application Layer Encryption, RBAC and ABAC
About the author: Scot Hutton is a retired Marine and current IT executive that puts people first. He leads the information security program for a 20+ billion-dollar real estate firm. He specializes in creating a better human experience and safe working environments with security controls that don’t limit human potential by focusing on “Security that Matters.”
Zero-Trust Encryption
Much like default deny firewalls where the firewall blocks all traffic and you have to create permit rules to allow traffic, zero trust security mandates that all identities have zero trust or privilege in an environment and only after they are authenticated do they obtain the most restrictive trust to complete their duties. Zero trust moves beyond just users, by honing in authentication and trust on users, service accounts, applications and devices, and perhaps even attributes. This means that users, applications, and devices should only have the access rights necessary to do their jobs.
Let’s take this a step further and instead of just focusing on access to information on a peripheral level, what about access to the data itself? The concept of zero-trust encryption, where access to data – by a user or system – is based on a set of attributes or a specific role, defined by an application.
An example: Does a system administrator who is responsible for the maintenance of the environment the data resides on need to see the actual data? Does this administrator need access all the time? Or just the applications running on it and only when evoked by an authorized user. Whereas a database administrator may need to see certain aspects of a database, but not necessarily every field containing PII.
But the concept of zero-trust encryption relies on the implementation of zero-trust security. Access and permissions are typically handled in two ways: Role-Based and Attribute-Based.
What are role and attribute-based access controls? Let’s dig in.
Role-Based Access Control (RBAC)
Role-based access control (RBAC) defines permissions based on the role a subject plays within an organization. According to NIST, “A role is essentially a collection of permissions, and all users receive permissions only through the roles to which they are assigned, or through roles they inherit through the role hierarchy.”
IIn an RBAC model, various roles are defined as part of the identity and access management (IAM) setup process, and these roles have certain permissions assigned to them. For example:
- A Finance Employee role may have access to corporate financial data but not HR records, IT systems, or employee performance data that a Finance Manager would need to do their jobs.
- In contrast, a Finance Manager may be able to access this performance data but lack access to some of the systems used by their employees.
Roles in an RBAC system are designed to be largely static because they are mapped to core business needs and the responsibilities of a particular type of employee. Employees are assigned roles, and permissions can be added to or removed from these roles as needed (such as the acquisition of new software).
Attribute-Based Access Control (ABAC)
One of the limitations of RBAC is that it lacks flexibility. An employee whose job role differs slightly from another’s requires their own role to encapsulate the necessary permissions.
Attribute-based access control (ABAC) provides an alternative to RBAC. NIST’s definition of ABAC is, “An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.”
In an ABAC scheme, a subject’s permissions are defined based on a collection of attributes. For example:
- A Finance Manager may be assigned attributes related to being in the Finance Department and being a manager.
- Some of these attributes would be shared with other Finance Department employees, and others would be shared with other managers.
With ABAC, access is determined based on the combination of the subject’s set of attributes. When requesting access to a particular resource, that resource will have rules associated with it that determine who can access it. If a subject’s attributes fulfill these requirements, then access is granted.
How existing at-rest encryption controls are failing to protect sensitive data
At rest encryption solutions such as full disk encryption (FDE) and transparent disk encryption (TDE) are common components of most enterprise data security strategies. Conceptually, they are very similar, as they focus on encrypting the data at the storage layer.
With full-disk encryption, all data on a system is encrypted with the same encryption key. And when an authorized user accesses the system, the system automatically decrypts all of the data. (In fact, frequently the data is fully decrypted on startup of the system and then only protected by the access control lists managed by the Operating System).
The same general approach applies to transparent disk encryption. For example, when applied to a database, a single encryption key is used to encrypt the entire database. And when an authorized admin (in this case a database administrator) accesses the database, the database decrypts all of the data.
Let’s explore this in a bit more detail using a database example.
Say an organization stores sensitive application data in Amazon RDS. As a standard security measure, they enable encryption on creation, which encrypts all of the data at rest. The beauty of this approach is that it’s easy and the database isn’t aware (and doesn’t even need to be) that the data is encrypted.
Despite the common use of these controls across most enterprises, most breaches result in the loss of sensitive data, whether it be PII or intellectual property. And many CISO’s face some variation of the following question for their boards after a major incident, “but I thought our data was encrypted. How were the attackers able to decrypt and steal it?
Unfortunately, the answer and reason are fairly straightforward, and well known within the security community. Most at rest, storage layer encryption solutions protect data from physical theft, but don’t protect against an attacker who successfully connects to the database using stolen authorized user credentials, admin credentials or by exploiting an application vulnerability. Even worse some database encryption blindly allows the account the application runs under to access the clear text version of data the second the application starts. In this case the security of all the data is passed up to the security controls of the application. Once the application or user is connected, the database automatically decrypts the data for the attacker, because it can’t tell between the authorized user or someone who stole the authorized user’s credentials.
So, to circle back to the Amazon RDS example above, if an adversary or insider threat compromises your AWS RDS credentials, RDS will provide the unauthorized user access to decrypted data… by design.
Some common examples of how some at-rest encryption can fail:
- A database administrator becomes an insider threat and abuses their database administrative access to read sensitive data directly from the database.
- A virtual machine with full-disk encryption is hosted in the cloud. A breach of the host machine enables sensitive data to be read from memory in a decrypted state.
While the criteria of encrypting the environment is met, it becomes clear that this encrypted state only matters if access does not exist. 48% of data breaches involve excessive permissions granted to an employee or contractor. In some cases, excessive permissions are provided by mistake, while, in others, security solutions don’t support them. So, no surprise that OWASP recently updated their Top 10 list to include A02:2021 – Cryptographic Failures as the second most common software vulnerability impacting web applications. In the above examples, full-disk and database encryption were unable to restrict access to only the data required by a particular individual. This is where the zero-trust concept becomes important in both access and encryption.
Strengthen data protection by integrating access controls with application-layer encryption
Application-layer encryption (ALE) enables a more granular and effective approach to data at rest encryption, than full-disk or database encryption. Instead of encrypting data in bulk, ALE allows an application to manage its own encryption, making it possible to tailor encryption to the unique security needs of the application’s data. ALE does this by encrypting data as it passes through an application regardless of the final resting place. Coupled with RBAC or ABAC, access to sensitive data can be restricted by specific user or system attributes and/or roles.
One scenario where ALE and access-based controls can help to limit enterprise risk and simplify compliance is customer service. To help customers with potential issues, a customer service representative requires access to basic account information and potentially billing history. However, they don’t need the ability to read a customer’s payment card information or other sensitive information provided as part of the account setup process. With ALE, customer service representatives can be granted access to only the encryption keys protecting the data that they need access to, making it impossible for them to breach or even access other sensitive customer data.
Case Study
Using ALE instead of a storage-layer encryption solution may have mitigated several, major data breaches. One example of where ALE could have helped include the Capital One data breaches.
Capital One Hack
In 2019, the Capital One breach exposed the personal information of approximately 106 million of the bank’s customers. The attack was made possible by misconfigured security configurations within the organization’s AWS environment. A web application firewall (WAF) was granted excessive permissions that allowed an attacker to exploit a server-side request forgery (SSRF) vulnerability to access data in cleartext.
Even with access to the server, the WAF should not have had access to the data stored on it. However, despite having full-disk encryption, users with a legitimate account had full access to the data stored on the system.
With ALE, data could have been encrypted by the applications that use it, so that unauthorized access to the storage server does not automatically translate to a data breach.
Zero trust encryption improves data security
Encryption is an effective tool to protect data privacy and security. However, traditional approaches to encryption today lack the effectiveness and granularity needed to protect against a constantly evolving threat landscape. ALE in partnership with RBAC and ABAC empowers an organization to implement lightweight, fine-grained encryption that enables effective access control and provides strong, zero trust protection against data breaches.
To keep up with our security, research, and cryptography content, make sure to subscribe to our blog below (in the footer section of this webpage).
Setup is quick and easy
Ready to get started?
Create a FREE account instantly and start encrypting data or get in touch to discuss a custom package for your organization.