Data Centric Security (DCS) and Zero Trust

What is Zero Trust?

Zero Trust is a security model that assumes that all users and devices, both inside and outside the organization's network, are untrusted. With this model, no user or device is granted access to resources by default.

The core principle is "Never Trust, Always Verify" - every access request must be authenticated, authorized, and continuously validated.

How does Zero Trust work?

Here's a high-level overview of the Zero Trust process:

1. Identity verification: The user is authenticated using multiple factors (username, password, MFA, biometric data).
2. Device validation: The device is validated to ensure it meets the organization's security standards.
3. Context evaluation: Environmental factors such as location, time, and network security level are assessed.
4. Resource classification: The requested resource is classified based on its sensitivity and importance.
5. Policy evaluation: All collected attributes are evaluated against organizational policies.
6. Access decision: Based on the comprehensive evaluation, access is granted, denied, or granted with conditions.
7. Continuous monitoring: Access is continuously monitored and can be revoked if conditions change.

What is Data Centric Security (DCS)?

Data Centric Security (DCS) is a security approach that focuses on protecting the data itself rather than the perimeter or infrastructure around it. DCS ensures that data remains secure regardless of where it resides or how it is accessed.

How does DCS work with Zero Trust?

Data Centric Security (DCS) implements Zero Trust principles by combining cryptographic protection with policy-driven authorization for fine-grained control over sensitive data.

Encryption Process

During encryption, attributes are added to the data based on classification and business rules. The data is then encrypted using a unique Data Encryption Key (DEK), which is itself encrypted and stored securely.

Decryption Process

Prior to decryption, the attributes along with additional information (e.g. JWT details, as specified in the KMaaS documentation) are sent to a policy server (OPA) for authorization evaluation. If the access is granted, the encrypted Data Encryption Key (DEK) is transmitted to the KMaaS service for decryption. The OPA policies must be configured and implemented according to your specific requirements.

This approach ensures:

• No implicit trust: Every data access request is verified against current policies
• Attribute-based decisions: Access is granted based on user, resource, environment, and action attributes
• Cryptographic protection: Data remains encrypted until authorized access is granted
• Continuous verification: Each access attempt triggers a fresh policy evaluation