The cornerstone of a viable zero trust solution is that it must be able to successfully handle the wide variety of applications, both legacy and modern, that are being used within corporations today.  While that statement seems obvious, it can be used to quickly differentiate between a comprehensive Security Service Edge solution and an offering that was rushed to market.

Starting from Zero Trust

Broad application support is critically important when trying to provide zero trust without compromises. Unfortunately, some vendors didn’t plan, design, or implement their solution to make this possible. Vendors that take shortcuts or simply did not want to tackle difficult problems end up leaving customers with huge security gaps in their zero trust implementations. Regrettably there are many examples of how companies suffer when vendors take ill-advised shortcuts. I prefer calling it an offering and I do not want to call what they provide a solution because it’s not really solving much of a problem. The only option they leave you with is to completely ignore the traffic sending it in the clear, or continue to use legacy VPNs.

Fortunately, not all offerings are created equal. From the start, the Banyan Security Service Edge (SSE) solution was designed to make sure we support and secure all applications. This includes VOIP, sometimes called IP telephony, which is a technology used over the past two decades by practically every company around the world regardless of size, location, or vertical industry.

How SSE and VOIP work together

Let’s dive in a little deeper to learn about VOIP and what a true SSE provider needs to consider when saying they secure all applications from anywhere.

VOIP software has two main flows: 1) session initiation using the TCP-based SIP protocol, and 2) media transport using the UDP-based RTP protocol. There are a bunch of additional protocols and variations that may need to be supported as well, depending on features enabled and devices used.

A ZTNA provider must support all of the required protocols, typically through some form of tunneling, to ensure that all types of calls are supported and ensure that all the related phone features, such as multi-person conferencing, directory lookup and voicemail, are supported.

Hidden VOIP Requirements You Should Know About

Often, a VOIP solution will have additional undocumented requirements, e.g., a dependence on reverse DNS or Reverse WINS. Some IP telephony devices, such as Cisco IP Phones, use DHCP option 150 and DHCP option 66 to push basic configurations, which then fetch full configuration files, background images, and other files from a TFTP server. Failure to meet these requirements typically leads to mysterious failures with unhelpful error messages.

While most modern applications perform correctly from behind Network Address Translation (NAT) firewalls (such as home routers), VOIP may not work correctly. Additional infrastructure such as Traversal Using Relays around NAT (TURN) servers must be deployed and configured in these scenarios. Support for incoming calls can be especially troublesome, because source NAT is incompatible with server-initiated traffic.

The Banyan Security Service Edge (SSE) contains a ZTNA solution that supports VoIP for remote users. The solution combines fast, lightweight service tunnels with least-privilege Layer-4 network policies and DNS control, along with optional ability to avoid requiring source NAT. This allows ZTNA administrators to securely enable fully functioning unified communications solutions using physical or virtual call platforms.

While we’ve detailed VOIP above, the same care and awareness goes into making sure our broad application support allows you to conduct business using the tools, equipment, and applications that your employees are comfortable and productive with. Our architecture allows you to easily enable, gain visibility of, and control access to applications and protocols while ensuring that your organization’s compliance and access needs are met.

Join our weekly live demo or schedule your own custom demo to get your configuration questions answered for VOIP.

Let’s look at some of the leading vendors of well-known legacy VPN products and compare them to Banyan Security’s Zero Trust Network Access (ZTNA) solution featuring Service Tunnel.

Limits of legacy VPN deployments

Physical appliances have numerous limits. You need to order them and wait for them to arrive (and sometimes make it through Customs), before you unbox, rack, wire, power-on, and provide cooling.

Also, have a single appliance means that both the control and data planes are on the same box. If either fails, there is no access.

Banyan’s ZTNA is cloud native using scalable, highly-available microservices. The Controller is in the cloud and completely independent of the data plane. You’ll have always-available, anywhere access with minimal fuss.

Deploying Active/Passive clusters are expensive. You buy hardware and licenses that are rarely used, if ever.

Banyan’s ZTNA model never charges for gateways or connectors. To get the performance, scale, and best experience possible, Banyan’s ZTNA auto scales as needed to ensure global availability. Deploy connectors to your disaster recovery (DR) sites if you’re deploying software there, all at no additional cost and little configuration changes. You can also automate these deployments using Terraform.

No need to touch the edge

VPNs require inbound and outbound access meaning you’ll need to log in to your edge firewall (FW) and open many ports. Not only does this take time, but each port that’s opened means the attach surface increases.

Banyan’s ZTNA connector does not require any inbound ports to be opened since it only makes outbound connections over standard, secure ports. Add as many ZTNA connectors in your data center or in your cloud provider as needed without ever having to log into your FW.

VPNs require external IP addresses on your DMZ which means logging in to your edge firewall (FW). Not only does this take time, but each external IP address may cost you money.

Banyan’s ZTNA connector does not require a static external IP address. Adding additional ZTNA connectors is possible without consuming a valuable external IP address.

VPNs require certificates which are tied to static hostnames. This means paying for SSL certificates and needing to update DNS records each time you add a single VPN appliance.

Banyan’s ZTNA solution is cloud-based so we automatically take care of DNS and certificates for all aspects of the solution. ZTNA connectors can be spun up without ever having to worry about buying a certificate or adding/updating DNS records.

Decision-less access

Your end user needs to know a lot about your architecture and where backend resources live. They must make the decision on where and how they must connect before they do their actual work.

Banyan ZTNA makes it very simple. End users log in to the Banyan app and are magically connected to all their authorized resources whether you have one office or hundreds of locations, physically or in the cloud. No more decisions, just productivity.

Tunnels made easy

Banyan Security’s vision is to help organizations migrate from inefficient, legacy VPNs and to do so introduced the Service Tunnel (ST) capability. The Service Tunnel isn’t for all members of the organizations. An organization that’s deploying using Zero Trust principles should deploy in the most secure, least privilege access method possible. For super users, and those with special requirements, a Service Tunnel can be the appropriate answer. The Service Tunnel is a tunneled, layer 4 connection to a single server and a specific port. A sample use case for this is when trying to local map a drive to a remote file server. The Service Tunnel can also be used when backhauling traffic that’s intended for a source-IP-validated SaaS application.

Service Tunnel configuration is simple and there a workflow (or wizard) that makes this possible:

The policy to allow the use of a Service Tunnel is also simple to configure. The authorization policy can be based on specific users, groups, devices, and/or a combination of these parameters.

The access policy can be to a specific IP and port, or it can be expanded to subnets, ports, and various protocols:

A single service tunnel can be used to connect to resources sitting behind multiple (or all) of your Banyan Connectors.

For the end user, the only decision that needs to be made is whether to access Banyan or not. Your end user doesn’t need to know where VPN appliances are deployed, or what backend resource is available through which VPN appliance. Simply log in to Banyan and be productive.

Next steps

1. Learn more about legacy VPN replacement
2. Sign up for Team Edition and quickly deploy a Service Tunnel
3. Learn more about getting started with Banyan’s Free Team Edition

As Banyan Security’s Chief Security Officer, I want to not only make sure that the Banyan organization and product offering are safe, but also that our customers and partners are secure.

First, we want you to know that the Banyan Security solution is not impacted by the breach recently disclosed by Okta related to Lapsus$. For more information on the incident please refer to Okta’s website: https://www.okta.com/blog/2022/03/updated-okta-statement-on-lapsus/.

We have taken steps internally to review our Okta tenant, accounts, and logs. We have confirmed that everything is in order and also that there is no evidence to suggest Okta’s incident impacted us as a customer.

Furthermore, the Banyan zero trust network access solution is often integrated with Okta as noted in our feature guide here:  https://docs.banyansecurity.io/docs/feature-guides/manage-users-and-devices/identity-providers/okta/.

Banyan’s approach provides user trust independent of device trust, to reduce risk in scenarios like this. Customers who use Okta with Banyan are better protected as a result of this philosophy.

There is no evidence to suggest that in this case Okta was not operating under the principle of least privilege, or that the 3rd party in question had excessive permission to access to the services and applications needed to do their job.

However, at time of writing, there is an open question regarding how a lost device can be unlocked and authenticated providing access into systems, especially if you assume a short session duration for a user with privileged access. We’re hopeful that in the coming days and weeks there will be full transparency and we will learn more.

Banyan mitigation & potential response for this attack

Here is a list of key activities performed by Banyan’s security team. We recommend you perform similar checks in your environments.

Mitigation for employee directory and corporate resources

• Review user directory – Banyan Security staff reviewed the user directory and ensured that all accounts created had IT tickets associated with them and were known employees. We made sure no Okta support staff ever had access to our systems (by looking for eventType “user.session.impersonation.initiate” in the System Logs).
• Review certificate issuance – Banyan Security staff used data compiled from Banyan APIs and the console to identify when certificates were issued to new devices. Any certificate issued to a user that was not in good standing would be revoked (none were found).
• Review Okta & Banyan audit logs – Banyan Security staff reviewed the administrative logs within the Banyan Console for anomalous or unexpected configuration changes and found none. Additionally, a review of Okta audit logs for indicators provided by Okta did not turn up any findings.

Mitigation for production environments (our customer data and systems)

In order to access customer data either through the administrative console or directly via the production infrastructure, there are additional controls in place that must be met that do not rely solely on Okta users and groups. As a result, there is no additional risk from this incident to Banyan customer data.

Additional course of action for Banyan Customers

Any customers who feel they would like to take additional steps are encouraged to change their invite code to the Banyan platform and revoke any device certificates issued by Banyan in the last 90 days (the suspected incident window). Your new users will have to re-register their devices with Banyan and procure new device certificates.

See our blog, “The Okta Breach and Securing SaaS Administration Interfaces” for more information on preventing such breaches.

If you have any questions about the Banyan zero trust solution, please do not hesitate to contact us.

Originally published by Robert Ronan, Oracle Principal Product Manager.

What is zero trust access?

As more organizations migrate infrastructure to the cloud and rethink software development and deployment, they are also modernizing their approach to security. One such approach is Zero Trust – instead of relying on traditional network perimeter-based security tools such as VPNs and bastions that connect you directly to a network, access (authentication as well as authorization) is granted based on user and device attributes as well as the sensitivity of specific applications and services within that network.

Zero trust access is particularly well suited to Infrastructure as a Service (IaaS) environments such as Oracle Cloud because traditional network security tools were not designed to handle the automation-oriented ephemeral nature of these environments.

Install Access Tier

To get started with Banyan Zero Trust Access, register for a Banyan account. You can use the Banyan Team Edition for free.

On a Linux VM in your Oracle Cloud Infrastructure (OCI) compartment with a public IP address, install the Banyan Access Tier component. This will serve as the gateway to your OCI infrastructure.

# add the Banyan RPM repo
$> yum-config-manager --add-repo https://www.banyanops.com/onramp/repo/
$> rpm --import https://www.banyanops.com/onramp/repo/RPM-GPG-KEY-banyan
# install it
$> yum install banyan-netagent

Other install methods – Docker, DEB, Tarball, Terraform, etc. – are available in our documentation. Once installed and configured, you will see the Access Tier reporting in Banyan’s Cloud Command Center console.

(Note: If you’re using the Banyan Team Edition, you will install an outbound Connector instead of the Access Tier; the Banyan global edge network of fully-managed Access Tiers will serve as the gateway into your OCI infrastructure.)

Auto-discover OCI resources

The next step is to synchronize your OCI resources into Banyan. You can use OCI tags to tell Banyan to discover only specific categories of resources in your environment.

$> banyan cloud-resource sync-oci all {oci-compartment} --tag_name banyan:discovery

--> Getting list of OCI VM resources:

type    name              public_dns_name    public_ip    private_dns_name    private_ip    ports    provider    region      tags
------  ----------------  -----------------  -----------  ------------------  ------------  -------  ----------  --------  ------
vm      oke-cqqhk6ivu2q-                                                      10.1.85.35    []       oci         phx            2
vm      oke-cko3n7f326q-                                                      10.0.93.236   []       oci         phx            2
vm      oke-cko3n7f326q-                                                      10.0.80.84    []       oci         phx            2


--> Filtering for new OCI resources:

type    name              public_dns_name    public_ip    private_dns_name    private_ip    ports    provider    region      tags
------  ----------------  -----------------  -----------  ------------------  ------------  -------  ----------  --------  ------
vm      oke-cqqhk6ivu2q-                                                      10.1.85.35    []       oci         phx            2


--> Syncing into Banyan Cloud Resource inventory:

--> Added OCIresource id(name): ocid1.instance.oc1.phx.anyhqljreqfgs5acfank3k2codj2srj4cnns3naalfttpmqjwk24digsi6qq(oke-cqqhk6ivu2q-nvp2thc5biq-
svjai5qusbq-2)

--> Sync with Oracle Cloud successful.

You can configure this sync to run at regular intervals so Banyan always has the latest snapshot of your OCI resources. In the Banyan Cloud Command Center console, you will see all your discovered OCI resources. You can now publish the individual resources your users need to access.

Publish a Service Catalog for your users

To publish an OCI resource as a Banyan service for your end users, simply select the resource, click Publish and follow the steps in the wizard.

Banyan provides native support for all the common services and protocols you can deploy in OCI:

• Web Applications (HTTPS)
• Linux Servers (SSH)
• Windows Servers (RDP)
• Kubernetes Clusters (K8s API)
• Databases (TCP)

Banyan also provides a WireGuard-powered Service Tunnel for use cases and protocols that cannot be handled by an identity-aware proxy.

Authenticated end users can now access these published services via the Banyan app – a cross-platform endpoint client that runs on Windows, macOS, Linux, iOS, and Android devices. The Banyan app also establishes the device identity and device posture checks needed for zero trust security.

Try Banyan on OCI Today

You can further organize your published Banyan services into bundles, create security policies to allow only specific sets of users to access certain applications, and more. Best of all, you can use Banyan Zero Trust Remote Access on OCI today! Sign up for the free Banyan Team Edition or request an Enterprise Edition trial account.

Original blog published at the Oracle Cloud Infrastructure Developers Blog.

I’m excited to write more about Banyan Security’s new partnership with Microsoft to help accelerate enterprise Zero Trust security adoption.

Today, most organizations are migrating their Identity and Access Management (IAM) away from traditional on-premises Active Directory to cloud IDPs such as Microsoft Azure AD. These cloud IDPs then serve as the employees’ portal to authenticate into multi-tenant SaaS applications such as Microsoft Office 365, Google Workspace (aka G Suite), Salesforce, and Dropbox. Employees enjoy a great user experience with click-button access from any browser, while the organization benefits from strong Zero Trust security using tools such as Azure AD Conditional Access, Risk Based Authentication and Microsoft Authenticator MFA that combines user trust, device trust, and application policies.

Many Sensitive Corporate Resources are NOT Multi-tenant SaaS

But not all corporate applications used by an enterprise workforce are multi-tenant SaaS accessible via the public internet – they require network connectivity and access controls that go beyond what Azure AD provides. This is particularly true in technology companies that build and deploy their own software, manage development tools and administer server infrastructure. Access to these internal applications and services is managed using networking tools like VPNs and Bastion hosts, often combining arcane authentication protocols with complex network segmentation rules.

A significant challenge faced by many IT teams today is to extend the Zero Trust security model that Azure AD enables into these hosted corporate applications, infrastructure and legacy environments. How do you maintain a strong security posture, while delivering the “cloud-like access” experience to applications deep in a datacenter? How do you simplify access provisioning and support approval workflows for infrastructure in the cloud?

This is where Banyan comes in.

Banyan brings the same one-click experience that Azure AD provides for multi-tenant SaaS applications to your corporate infrastructure – be it in the datacenter, on-premises, or IaaS. You can now modernize network access and roll out Zero Trust security as part of your overall Azure AD migration strategy.

Dead Simple Deployment with Zero Trust Security
Banyan’s modern cloud-based architecture allows you to quickly provision access into datacenter and IaaS environments. Just deploy a simple Banyan component on a server in the datacenter or IaaS clusters where your corporate resources are hosted. After that, you can provision access to your resources using our Cloud Command Center web interface or APIs. Banyan enables Zero Trust security, ensuring every access to your corporate resources is explicitly authenticated and authorized. No more logging into traditional VPNs and bastions and manually updating keys and ACLs.

Because Banyan has built-in integrations with Azure AD to establish user trust, you can manage access policies for your servers and internal applications just the way you do for other applications in Azure AD using Azure AD groups. For example, you can quickly provision secure access for BYOD and third parties to specific applications without ever giving them VPN access to the corporate network.

Banyan provides native desktop and mobile apps, and also integrates with other tools in the Microsoft ecosystem such as Endpoint Manager and Defender for Endpoint, so you can establish device trust and quantify overall security posture with a trust score. Now you have trust-based access control policies that account for user identity as well as device trust and posture, significantly improving security.

By pairing Banyan with Azure AD, access to hosted corporate applications and infrastructure is restricted by policy to trusted users on trusted devices, delivering a Zero Trust security model for your organization. Best of all, your users now gain a “cloud-like access” experience that doesn’t involve logging into VPNs and bastions. See how easy it is for an Azure AD user to access a Linux server hosted in a datacenter…

“Banyan Security’s integration with Azure AD extends zero trust access controls to all types of resources, making it easier to stay secure in the hybrid work environment.” – Sue Bohn, partner director, Microsoft Identity at Microsoft.

Ready to extend your Azure AD investment to deliver Zero Trust security? Read up on how you can get started in the Microsoft Secure Hybrid Access docs, or try Banyan for yourself via the Banyan Team Edition. We look forward to accelerating your Zero Trust journey!

…and continuous authorization is only possible with real-time device trust and a means to instantly revoke access.

Let’s face it, most professionals in enterprise information security would agree that when it comes to secure remote access, Zero Trust is the right strategy for our modern workstyles and modern corporate infrastructures. The vast majority of both our workers and our resources are living outside of the now-outdated corporate perimeter. So there is consensus that we must find a new way forward with cybersecurity and information systems if we intend to support the productivity of remote workforce – while effectively protecting the sensitive resources that support that productivity. The experts have all spoken – Zero Trust is the answer.

Great! Sign me up for some Zero Trust.

But I’m like you, and I do my research to learn just what that means so I can implement the best Zero Trust around. What I learned is that Zero Trust is a security strategy or even philosophy based on the idea that we should not assume or imply trust as part of any access request based only on history or anything we think we already know about the requestor.

We used to assume that our corporate networks were trusted, so anyone able to join that network was also assumed to be trustworthy and not a cyber risk. The same goes for our VPNs. The corporate laptop we issued with the carefully crafted image was secure when we issued it, so any activities on that device were also assumed to be trusted.

You get the point – for many years we have relied on historical beliefs and insufficient validation to grant broad access to our sensitive stuff without fear of cyber threats.

With Zero Trust, we take each request for an app, system, or resource as a separate transaction that starts with zero implied trust. This solves multiple issues. It addresses the too-broad access by requiring new authentication for each resource requested, each time. This ongoing authorization effectively shuts off lateral movement within an environment or network.

A Zero trust cybersecurity posture also ensures that in case anything bad has happened since the last successful access, we have the opportunity to deny that new request. Maybe credentials have been stolen and the requester isn’t really who they say they are. Maybe their device has been compromised by malware and it would no longer be safe to allow that device to be used for sensitive activities.

These safeguards sound pretty good, but have we truly addressed the trust problem?

It occurred to me that bad things can (and do) happen at any time. When I’m out and about, I often move from one Wi-Fi to another and not all are safe. I sometimes discover a cool new app to install. I check my email and browse the internet and click on things while I’m working. All of these are activities that anyone in the security business will tell you are potentially risky, and any one or more of them could add risk to me as a consumer of corporate material.

Then I asked myself how often I authenticate into the many systems I rely on to do my work. For many of them, it’s only once a day.

That’s when I realized that one-and-done authorization violates the very principle of Zero Trust. In the same way that one authentication into the castle perimeter exposed far too much to every user, one authentication into an app then leaves that app exposed and potentially vulnerable for the entire duration of the requester’s access. Trust established at a single point in time does not guarantee enduring trustworthiness.

The logical conclusion is that in order for a Zero Trust solution to be effective in its execution, it not only must establish trust at the beginning of each request, it must continuously verify that the request remains trustworthy throughout the entirety of the transaction. Only then will we have truly lived up to the Zero Trust principle. In other words, Zero Trust is only useful when continuous authorization is part of the strategy.

So, what would such a solution look like and how would it work? In order for continuous authorization to work in practice, two things are required:

1. Continuous Quantified Trust – Constant, thorough analysis of the trustworthiness of the user and their device.
2. Instant Access Control – The ability to instantly revoke access if trustworthiness falls, and instantly re-grant access if trustworthiness rises sufficiently.

These are clearly more than mere features of a Zero Trust solution – they rely on an architecture that supports broad integrations and the ability to respond in real time. Let’s take a look at each of these in more detail.

Continuous Quantified Trust

When I think of trustworthiness, it occurs to me that trust is never truly a binary decision. A person gradually earns trust with their peers over time, earning greater amounts of trust as there are more data points that support trusting that person.

In an IT system security plan, users also establish various levels of trust through multiple points of verification. For example, entering the correct credentials may set one on the path toward trustworthiness, but most IT security experts agree that that level of trust is simply too low. So, we add additional factors (like MFA and device trust) to attempt to elevate the trustworthiness until we are satisfied that the trust is high enough to grant access.

If we were to add a bit of rigor to this process, we could say that we are calculating a trust score. We could even decide that a minimum score is required prior to granting access to certain resources. Let’s say that we agree that a higher trust score would be required to access the company’s financial records than would be required to access the corporate cafeteria menu. Just because we don’t trust someone with our most sensitive records, doesn’t mean we need to starve them. Trust is not binary. Risk tolerance is relative to the sensitivity of the asset.

Clearly, we want to be thorough in our measurement of trust for sensitive material, and that means verifying that the user is truly who they say they are and the device they are using is authorized and proven to be low risk. Fortunately, most organizations have already implemented a variety of security controls to help with this, and we simply need to tap into those sources so they can all contribute to this calculation of a trust score.

For most organizations, these tools generally operate in silos, at the most sharing information with a SIEM system. Wouldn’t it be great if we could leverage all of these user and device security tools as data points in a trustworthiness calculation? If we were really clever, we would also figure out additional indicators, like evaluating for recognized patterns of behavior and other circumstantial evidence of trustworthiness.

Zero Trust solutions typically leverage an identity solution as the starting point, but often don’t go any farther. I think it is important to not only identify the person, but also verify that their behavior, location, time and frequency of access, and many other factors are taken into account as well. Next, just like identity, even the Zero Trust solutions that mention Device Trust simply don’t take it far enough with real-time integrations with solutions that are already functioning in most organizations. To establish the best measure of trust, we have the opportunity, and even the obligation, to evaluate not simply the measurable attributes of identity and device, but also the activity, behaviors and transitory characteristics of both. The graphic below shows sample solution categories that may contribute to the Trust Score. Additional logic, including artificial intelligence could further enhance the accuracy of the trust score.

So, the first of the two requirements is this ability to collect and continuously evaluate all of the best telemetry from the available solutions in the organization, in real time. That way, we will know the instant something bad happens by observing a reduction in the trust score. Now, if we could only take appropriate action based on that score. That is where the Instant Access Control piece comes into play.

Instant Access Control

Zero Trust solutions already have the ability to mask corporate resources and only grant access once trust has been established, whatever ‘trust’ may mean for each solution. Having the ability to revoke that access at a moment’s notice is another thing entirely. There must be a continuous connection with the trust score engine and the policy engine, and this access control tier has to be able to re-establish that cloaked state the instant the trust score falls below the threshold for that resource.

This is clearly the simpler element in the equation relative to the trust score. However, there can be some intelligence built in that takes into account the score required for the particular resource being masked. If a reverse proxy is used for this purpose, it can also serve to add additional functions like load balancing and DoS protection. If cryptography is used in the form of a ‘trust token’, then additional characteristics and variables may be embedded to add more intelligence to the decision making, and may even be able to store state in the case of a partial system failure.

Visibility and Self Remediation

One of the biggest complaints I often hear about secure remote access is how much IT resource can be consumed just in support tickets, whether it be users unable to gain access, or they’ve lost access and want it back, or they need access to something they didn’t previously have access to. It occurs to me that this trust score could be incredibly useful in reducing that IT burden, if we simply make the score visible to the end user.

Let’s say that we make the score visible on the end-user’s device and include a list of the primary factors that are considered in calculating that score.

For example, through continuous monitoring we can report whether the device is running a recent version of the operating system, is using disk encryption, has the required anti-virus program running, etc. If that user loses access to a resource they had been using, they would be able to easily see that their score went down and identify which factor or factors are contributing to that decline.

In many cases, since it is likely due to something the user just did, like joining an insecure Wi-Fi, or installing malware, they would be able to take corrective action, like disconnecting from the bad Wi-Fi or removing the app.

The same system that detected the reduced trust score and revoked access would just as quickly detect that the trust score went back up and could reinstate access without any demand from an already overburdened IT department.

Users can be in charge of their own security at that point and are now able to remain productive more often, all on their own. In fact, the users may end up better educated on risky behaviors and act in a more secure manner in the future. That’s a win for everybody.

In Conclusion…

Zero Trust is just a concept, not a product. But it is the right way to think about assessing cybersecurity risk in the modern world of flexible workstyles and crumbling perimeters. Based on my studies, if we are to truly benefit from what Zero Trust has to teach us, the principles must be applied thoroughly and continuously. Otherwise, we may be fooling ourselves that our sensitive corporate resources are well protected, when in fact we’ve only secured them for a single moment in time.

As you evaluate Zero Trust solutions to provide secure access for all of your remote workers, be sure the architecture supports broad integrations with all of your identity and endpoint security products. Be sure as many attributes and activities as possible are measured to establish a sufficiently high degree of trustworthiness. And, finally, be sure that the solution has continuous authorization, because bad things can happen at any time.

Learn more about Banyan Secure Remote Access.