Zero Trust is a security model that assumes you can’t by default trust users, applications, or devices accessing a given service just based on location or network. It is a policy-based framework that is used to evaluate trust whenever any asset belonging to an organization is accessed.
Before Zero Trust
There are several disadvantages with trusted location architecture, particularly that the user or device would be entirely trusted even if compromised, either because the user’s password was stolen, or someone else gained control of the device. Managing network segmentation was also expensive and could quickly get out of hand. However, with the rapid adoption of cloud- native and DevOps, this model became untenable. Especially, as data moved out of self-managed infrastructure into SaaS based repositories and applications, the concept of location lost its meaning. Coupled with the increase in sophistication and frequency of threats, often aimed at users’ credentials, the need for Zero Trust was born.
Zero Trust model entails that whenever an asset is accessed, multiple checks, or policies, are applied to validate the user and device health before allowing access. These policies are based on three principles:
- Establish identity of users and devices before allowing access
- Eliminate location as the sole, one-time attribute allowing secure access
- Lock down all access unless specified with a strict set of policies
This isn’t done using a single tool but a combination of various solutions.
Using Single Sign-On (SSO) enables authentication, eliminates weak passwords by removing the need for users to separately manage credentials for each service, and makes it easier for security and IT teams to centrally manage users, and govern access to applications. Device validation for each access request, coupled with visibility and reporting. Similarly, Multi-Factor Authentication (MFA) allows users and devices to be verified to protect against the case where credentials get compromised unbeknownst to them. Once a device and user identity have been established, fine grained access policies can be specified to allow access to certain applications and perform defined functions. Companies use the concept of least privilege to make sure users have access to just enough privileges they need to be productive.
Historically, this has worked well for applications, but having federated identity management and fine grained access control has proven to be much more difficult at the data layer, comprising of databases, data warehouses and pipelines. Especially as data repositories have moved to the cloud, and engineering teams have gained unfettered access to manipulate data for product innovation, the attack surface has widened.
For one, most data layer components don’t integrate natively with common SSO and MFA providers that require support for SAML or OIDC protocols. So while users can use SSO and MFA for access to applications, data layer access still relies on ad hoc user management. And applications rely on service credentials which further abstract the ability to log and audit the application or service accessing the database. So without individual or application attribution and lack of fine-grained logs, this makes most Zero Trust implementations break at the data layer.
Enforcing Zero Trust at the Data Layer with Cyral
Cyral has made it simple to extend Zero Trust across all data endpoints while respecting the three principles of Zero Trust. Cyral links together SAML authentication with access to all data layer components in one place. Onboarding users with the right roles now can continue to live in your identity provider, and then traced through every query they make, either through BI tools or direct database access. Cyral policies can be defined down to the field level. So you can be sure that users and applications are only allowed to do exactly what you specify. To learn how Cyral’s patented technology can help your organization extend Zero Trust model to the data layer, sign up for a demo here.
Anomaly detection refers to the process of identifying unusual items, events, or observations. Those items raise suspicion by differing from the normal and expected behavior. …
When one talks about API security the focus is typically on public facing APIs. As digital transformation efforts take hold internal API also become critical …