Zero Trust Architecture  (ZTA)

Organizations are increasingly adopting distributed environments due to changes in the technology landscape, such as cloud computing, edge computing, mixed with  the evolution of social behavior, that  has resulted in expanded mobility. The result is an increase in complexity for networks and service architectures driven by the need to connect remote offices, remote workers, contractors, smart objects, and others which has reinforced the requirement for flexible, scalable, and secure network, asset, and data protection capabilities.

Data often resides in virtual environments outside the organization’s premises and its physical control, yet the organization is still accountable for the data. Traditional security architectures that focus on securing the physical network perimeter are not effective in preventing cyberattacks.

As with most security architectures, the primary objective of ZTA is to address security risks inherent in the assumption of trust, and the lack of proper access controls. Typical approaches to addressing these risks include reducing the attack surface and/or improving the effectiveness of security controls (Source: Cloud Security Alliance).

A ZTA creates virtual enclaves (logical constructs of IT resources that can include data stores), to which consumers are  granted access inside a particular enclave for a particular purpose. Every transaction follows the ZT concept of “never trust, always verify”.  In a ZT environment, every access to a service is verified.

ZT provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. In other words, ZT is a set of principles and practices designed for reducing security risks; this is implemented through authentication and verification for each consumer attempting to access data resources, irrespective of its location (inside or outside the perimeter). Security posture is not based on location, but on authentication and authorization controls in place, and by leveraging risk-based analytics for access verification.  The goal is to prevent unauthorized access to data and services and make access control enforcement as granular as possible. ZT follows this approach:

• Never make assumptions about an entity’s trustworthiness when it requests access to a resource.
• Starting with no pre-established entitlements, then relying on rules/policies  that add entitlements, as needed.
• Verify all users, assets, workloads, network, or data access always assuming that a breach is impending or has already happened.

Denodo Security Capabilities in a Zero Trust Architecture

“A ZT approach fulfills both technical and business objectives. Technically, it establishes a framework for protecting resources, simplifies the user experience, reduces the organization’s attack surface size and complexity, enforces least privilege, improves control and resilience, and localizes the impact radius of a security failure.” Source: Cloud Security Alliance, Introduction to Zero Trust Architecture.

Denodo helps in ensuring secure transfer of data, consistently applying access privileges to objects in the semantic layer that federate data sources, providing data lineage to understand where data is coming from, providing full audit capabilities to understand who is accessing which data, masking sensitive data to ensure it is not accessed by unauthorized users.

Denodo offers several capabilities for use in a ZT environment:

• Secured communication: All Communication is secured using TLS (1.3 available) on all incoming connections (HTTP, JDBC, ODBC) and all connections are authenticated against enterprise directories. Outgoing connections to secured data source resources with trust configurable via standard Java trust store.
• Access per session: Denodo provides real time data within a session, so a consumer never has direct nor persistent access to underlying sources where data is stored, and nothing is stored in the platform as the results are delivered to the client. Authorization is reevaluated on every session.
• Dynamic policy access to resources: Lightweight Directory Access Protocol (LDAP)  or Single Sign On (SSO) integration for Authorization, plus Global Security Policies (GSPs) and/or Relationship Manager (RM) driven behavioral and environmental attribute controls.  
• Monitor and measure:  Monitoring of not just the Denodo platform usage real-time but - if needed - integrating all asset logging for comprehensive analysis and continual improvement of the integrity posture.
• All resource authentication and authorization are dynamic and strictly enforced before access is allowed: Identity, Credential, and Access Management (ICAM) and Multi-Factor Authentication (MFA) plus conditional monitoring and  Java Management Extensions (JMX) session expiration
• Collect as much information as possible: Monitoring plus ingesting/being ingested for ongoing enforcement efforts.

Authentication and Authorization

The Denodo Platform supports user and role-based authentication and authorization mechanisms with both schema-wide and data product specific permissions. Denodo offers very fine-grained access down to the cell level (applying both row-based and column-based security) including the possibility of masking specific cells (e.g., managers are not allowed to view the “salary” column of higher-level management, so those cells would appear masked in the results). Denodo row-based security usually does not require any coding, and it can be defined by access managers graphically within a natural language context.

Denodo can leverage your preferred IAM tool to delegate authentication to it and to obtain the authorization credentials or entitlements (roles and attributes) necessary for the consumer (user or application) to access data resources. Denodo offers data source pass-through session credentials so that the user credentials are reauthorized when attempting to connect to a particular database. It is important to note that Denodo Unified Security Management offers a single point to control access to any piece of information, therefore simplifying the security architecture, a core tenet of ZT.

Denodo implements security policies through its Global Security Policies (GSPs) Module based on semantics leveraging tags instead of data artifacts.  These are abstracted from the physical data sources underneath and are easier to manage and less error prone.

Denodo secures access from consumers to final data sources end-to-end, with capabilities to customize these GSPs in the data abstraction layer, and centralizing security when data is spread across multiple systems across the enterprise. Denodo provides governed secure data access. Note that these policies are instruments that act on consumers, consumer attributes, or consumer roles over predefined tags. Examples of tags can be those related to PII data or data classification.

Examples of GSP rules:

• Mask the contact information such as “email” or “sensitive” with *** for Data Scientists.
• Mask “SSN” tagged data for non-HR consumers.
• Mask “sensitive” data for users belonging to a “partner” role (ABAC).
• Limit rows based on user attribute and role.

An Independent definition of policies based on tags from the development of the security model allows distinct designation of who is responsible for each task. Governance teams may define the policies while data stewards are responsible for identifying the data assets under their purview.  ZTA would further audit both decisions as part of the Security Testing in both the QA cycle and ongoing Production security posture integrity monitoring.

In regard to the Security Tags defined in Denodo:

• Tags are available at the column and view level to easily identify and classify data.
• Tags can be imported from external governance and inventory catalogs, such as Collibra and others.
• Tags allow for implementation of semantic security rules across the data landscape.

Tag-based GSPs Support RBAC and ABAC ensuring extended flexibility for diverse use cases. They also support extended masking based on data types and support for customizations.

Auditing and Monitoring

Inside Denodo a consumer cannot access a view or data if their combined role memberships and session attributes do not grant that privilege.  

In addition, from an application perspective Denodo can help identify lateral movement attempts through the analysis of access/audit logs. Denodo monitoring audit logs will spool all Data Definition Language (create, drop, replace…) and Data Manipulation Language statements (select, insert, delete…) along with logins and logouts. 26 dimensions are logged including server, host, port, id, user, database, session id, duration, VQL, etc., which can be used by an AI/ML tool to identify breaches.

As a Java application, Denodo can be accessed real time via JMX making analysis and response faster.

• Auditing information can be found at the Auditing User Access in Virtual DataPort document.
• Monitoring information can be found at the Denodo Monitoring Community Page.

Anonymization

The are several options for data anonymity:

• Encryption – It is possible to use Denodo encryption or integrate with other products.

• Using secret keys to generate ciphered data: This process is reversible.
• If a key is intercepted, it can be used to decrypt all of the data it was used to secure.

• Tokenization – Can be implemented with third party products.

• Using tokens to protect data. A database houses both tokens and the real data.
• If a token is intercepted, it cannot be used to guess the real values.

• Masking – can use Denodo masking capabilities.

• Hide the original values based on the predetermined masking rule.
• It is impossible to “un-mask”, as the original values are removed and replaced with masked information.

Denodo offers the following techniques for data anonymization:

• Masking: Such as Hash functions: The Denodo Hash function will create a unique Character set based on the original value that was hashed. You can hash join columns.
• Encrypt/Decrypt: Use Denodo encrypt functions to have more control over the algorithm used to encrypt the information. The algorithm refers to a PBE encryption algorithm and supported by the default JCE of the Denodo Platform JRE.
• Integration with third party systems: Custom functions that integrate with external data protection systems.  For example, Denodo would pass the User Id and the tokenized value to a protection system function. The protection system will do a lookup for that User Id and value and will return the de-tokenized value.

Encryption in Motion and at Rest

All communication between the Denodo Platform and the Data Consumers/Data Sources, as well as between the different modules within the Denodo Platform, will be secured through SSL/TLS at the connection level. It supports any encryption algorithm supported by the default Java Cryptography Providers of the Denodo Platform JRE (Java 8), or by any additional provider, registered as part of the Denodo Platform JRE. As an extra layer of security, Denodo´s built-in functions for encryption/decryption can be selectively applied to sensitive fields to prevent unauthorized access: The same applies to tokenization leveraging third party products.

Denodo has query acceleration capabilities. These involve the materialization of federated data products in relational databases of your choice. Data at rest will have to be encrypted, typically through Transparent Data Encryption (encrypted data to prevent access to the data from the operating system

During the data delivery process, it is possible that the allocated memory buffers for query execution are full: In this case, the execution engine will swap data to disk. In these cases, leverage your Operating System file system encryption for the location where those swap files reside.  

No user data is stored inside Denodo, just metadata about the enterprise abstraction layer, namely the data mesh/fabric built with this enterprise tool. This metadata is stored by default in a derby database, although it can be externalized to other databases such as MySQL, PostgreSQL, etc.

Sensitive information, such as service accounts to access data sources and users accounts are stored encrypted or hashed in the Denodo metadata repository. In addition, you can enable transparent data encryption to encrypt the Derby database or external metadata databases so it would apply not only to sensitive data, but to all the metadata. After enabling this feature, the metadata is transparently decrypted when it is accessed so the users do not need to be aware that the metadata they are accessing is encrypted.

From a DevOps perspective, sensitive data within metadata migration and backup files is encrypted.  A password is used to encrypt sensitive data in the generated metadata migration file.

Security Certifications

Denodo does not store any data, only metadata about the systems it connects to and the abstraction layer built on top of them.  In those cases where query acceleration capabilities are leveraged, the data is materialized in data stores external to Denodo.

• Denodo has an ISO 27001:2013 certification.
• Denodo Veracode Verified Standard.

The functionality provided by Denodo has helped our customers to comply with GDPR, HIPAA, US Government ATOs (both Federal Civilian and DOD) and other data security and privacy regulations.

As of today, Denodo does not provide hosting services. Denodo software will be installed where the customer designates, so ISO 27017, ISO 27018, SOC1, SOC2, SSAE 16, SAS 70 nor ISAE 3402 do not apply. Denodo follows the application development security guidelines and best practices, as stated in those standards. We are currently working on a SaaS solution that will conform to accepted security standards such as SOC2.

Conclusion

A modern data architecture must balance the physical collection of data, as occurs in a centralized architecture, with the logical connection to data, which occurs in a decentralized architecture. Logical data management provides a unified, simplifie,  governed and secure data access layer across all enterprise data assets that enables immediate access to any dataset without needing first to copy or replicate it.

Denodo is very well suited within a ZT environment. Data is secured by default and has developed industry-leading capabilities in key areas such as authentication, authorization, and anonymization. Used together, these capabilities help protect your enterprise data from outsiders and internal users who otherwise could gain unauthorized elevated access.

From a ZT perspective, the benefits of logical data management include:

• Centralized security and governance: Access control and policy implementation are applied at the single logical data access layer, ensuring consistency. Security policy changes take effect immediately.
• Ease of use: Consumers have a single location from which to access any data and for InfoSec to monitor the access. IT has a central point to define access rules, to monitor and over which to act.
• Agile secure data integration options: One platform supports the full range of data integration options, including full replication and transformations, caching, and real-time federation. All security rules applied to the Denodo abstraction layer are inherited by all consumers irrespective of location. All new data products can be assigned to existing or new tags so that they are automatically protected through global security policies that have been defined as applied to these tags and consumer profile (roles and attributes)
• Futureproof: By decoupling access to data from the underlying data sources, IT is free to change underlying data stores without affecting business users. From a ZT perspective, you protect the data products from the canonical model exposed to your consumers once so that you need not reimplement these rules once more when you reimplement or modernize applications.