Identity Defined Security Alliance

Putting Identity at the Center of Security

Zero Trust Integrations

The IDSA has chartered a Technical Working Group to investigate and develop guidance on the role/impact of identity-centric security on Zero Trust initiatives. We’d like to get feedback from the community to inform this process.

Vendors - tell us about your integrations that you categorize as enabling zero trust initiatives.

Customers - what integrations do you have deployed to support your zero trust initiatives (or what integrations do you need)?

2 Likes

Centrify has developed some very important Zero Trust integrations with other IDSA members…

PAM least privilege and IGA/Workflow:

  • Centrify has certified integrations with both SailPoint and ServiceNow for customers to do privilege access request and approval including managing temporary least privilege roles.
  • Follows Zero Trust principles by implementing least privilege access

PAM access and IDaaS federation:

  • Centrify can be an identity provider, but also has proven integrations with both Idaptive and Okta (really works with any federation std) to utilize the IDaaS as the Identity Provider and Centrify as Service Provider that gives secure access to customer’s infrastructure through a secure distributed jumpbox without the need for VPN.
  • Follows Zero Trust principles by improving secure access with using temporary tokens rather than static credentials for access and enabling the use of centralized individual identities and reduced leverage of local and shared accounts.

PAM access and MFA:

  • Centrify has its own MFA capability but also proven integrations with YubiKey, Duo, Okta, Idaptive to leverage their MFA capabilities for privileged access.
  • Follows Zero Trust principles by adding an extra step to “verify the user” at ALL stages of privilege access. MFA applies not only at login to the password vault, but also at credential checkin/checkout, for login directly to server as well as for privilege elevation.
3 Likes

I think those that know me know that I’m a huge proponent of zero trust, dating back to the it’s inception by Forrester in 2009. Though, like many others, I didn’t get real serious about zero trust until I ran across Google’s Beyond Corp initiative, when it was still in development, a year or two later.

Fast forward a few more years, Google completed their zero trust journey and I decided to start our own zero trust journey here at LogRhythm. We’re about half way through our implementation of zero trust and planning to be fully complete by year end. I’ll be sharing that story and a bit more about zero trust in an upcoming blog.

From a tech stack perspective, we’ve aligned capabilities from the Google model to commercial, off the shelf, products. We’re leveraging Okta for IAM (including MFA and SSO) and have it fully integrated into our HR system (ADP) as the single source of truth for employees. We’re leveraging Okta’s ScaleFT product as our light weight PAM. We’re going to use VMWare’s Workspace One for device trust, LogRhythm for the SIEM/UEBA/SOAR component that can also be an attribute used in trust inference, and actively reviewing our CASB options to act as the policy broker and access proxy (Netskope or Skyhigh) and our micro segmentation strategy, and subsequent tooling, as well. We’ve built integrations and automations across the tech stack and seen some tremendous benefits in doing so both from a security and IT operations perspective. The upcoming blog will have all the details related to our implementation, including diagrams of what our implementation looks like, architecturally.

In the meantime, I thought I would share a blog I wrote, about a year ago, on the topic of zero trust.

I would love to hear other thoughts, opinions, success stories, and failures on zero trust!

4 Likes

Like many security professionals who have been in the industry for a while, my interactions with zero-trust style computing started long before it was called “zero-trust”. Back in 2004 we published a research paper regarding our work on making smart cards autonomous peers on the mainstream computer network. This paper (“Secure Network Card: Implementation of a Standard Network Stack in a Smart Card”, ISBN 978-1-4020-8147-7) enabled end-to-end secure communication between applications running on smart card and any remote server on the Internet. One reason we developed this model of communication was to remove the “stitching-point” inside a PC the smart card was connected to. Why? Because we did not trust the computer. The goal was allow smart card to talk to a remote server without anyone else listening to the communication, not even the PC that belonged to the user. Several applications were developed using this model.

The current zero-trust model focuses on the same principal of trusting no one, but also adds frequent checks at the point of data or application access. These checks are repeated at each interaction, or as defined by the business model.

On this theme, we (Thales) recently worked with Ping and BeyondTrust to demonstrate a zero-trust integration, which was presented at the IDSA master-sessions in Identiverse 2018. The title was “Delegation of access management and trust elevation for privileged access”.

  • Thales (Access Management, 2FA)
  • Ping (Single Sign-On)
  • BeyondTrust (Privileged Access Management)

Details regarding this zero-trust integration as as follows:

PingFederate provides single sign-on (SSO) capability so users can login to service providers (SP’s) and has a well-defined method to delegate two-factor authentication (2FA) to third parties. This 2FA delegation is done through adaptors, integration kits or simple configuration from admin console.

Thales has two products. SafeNet Authentication Service (SAS) supports a wide range of 2FA options (such as hardware OTP tokens, GrIDSure, mobile OTP, push OTP, SMS, etc.), while SafeNet Trusted Access (STA) product provides SSO and access management (AM) capabilities.

BeyondTrust provides privileged access management (PAM) solution through PowerBroker platform, which can control admin/root access on Windows and Linux servers.

All these products use open standards (e.g. SAML, OIDC, RADIUS etc.) and can therefore interface with other third party products. In this demo/integration we will demonstrate the following capabilities. Connection to SP’s and SSO is handled by PingFederate, PAM is handled by BeyondTrust, while AM and 2FA are handled by Thales via STA and SAS respectively. This integration demonstrates how different components from different IDSA member companies can work together to offer SSO→AM→2FA→PAM chain of service to customers.

Scenario 1: A user goes to a service provider (e.g. Salesforce) which relies on Ping for SSO. Behind the scenes, AM and 2FA is provided by Thales. Conversely service providers that rely on Thales can now instead point to Ping for SSO, while still maintaining AM and 2FA services from Thales. It could be possible to get additional permutations, but that is outside the scope of this integration.

Scenario 2: An admin goes to a BeyondTrust app to start a VM image. The initial authorization to launch the VM image is done by using PingFederate for SSO, STA (Thales) for AM, and SAS (Thales) for 2FA. The admin then issues an elevated command within the VM console that requires additional privilege or re-authentication. BeyondTrust command shell intercepts the elevation condition and sends a 2FA request to Thales, to do step-up authentication. Once step-up authentication is done (e.g. by sending a push notification to admin’s phone) the privileged command is executed.

At VMware we’re building a portfolio to enable Zero Trust across both user space and the data center. Workspace ONE (WS1) is the EUC product that serves as the glue for many Identity and Access Management providers and integrations:

Device Management & Configuration — WS1 enables over-the-air configuration and management (UEM) of devices, enabling security vendors to deploy and update their solutions to users with minimal user oversight. This permits both periodic and real time device sampling to influence decisions around application access. Additionally, configuration profiles can be dynamically assigned to devices, allowing for automated identification and remediation of security concerns on devices.

Access Control Plane — WS1 provides Identity and App tunneling solutions to provide security across cloud-federated and network-secured applications. This allows for unified approaches for conditional access without the need to design app-specific solutions. Based on admin-defined policies, WS1 can automatically revoke access to sensitive apps.

Data, Data, Data — WS1 offers a robust Intelligence and Compliance engine, allowing for the aggregation of security related information, as well as the automation of controlling access to applications based on different policies and security markers collected from an ecosystem of security vendors.

Check out one example architecture here for how to achieve Zero Trust with Workspace ONE: