Ok, y’all, we are now in the middle of post-covid work environments where the freedom of location has been a selling point for companies that have remote positions. But this freedom pairs with the adage “with great power comes great responsibility,” where we are relying on our end users to police their own internet activity. Here’s where internet threat protection comes in.

From a security standpoint, this is a rather difficult problem; our biggest line of defense for malicious activity and compliance has been managing the thing that makes connection to the internet on employees devices function. And we already know from when we implemented these tools (what seems like eons ago): employees that felt unsupervised will sometimes do things with their devices like no one is watching; whether in ignorance, acting from defiance, or the ol’ DGAF, I will let you be the judge…

For those familiar with children and computers that are school property, you know the above sentiment all too well. Children will do almost anything to get to the corner of the internet that they are trying to view. They eventually land an arsenal of tools like VPNs, archival sites, and translation sites to avoid the intended class work and instead continue on in the Minecraft mission (or worse).

The Internet Threat Protection Problem 

Possibly having witnessed this firsthand, you’ll recognize that our task is to manage the internet traffic that can come from a corporate device as best as we can while not annoying users with the controlled access point. Might I add, rightly so. As you find yourself in this problem of having to manage employees like they are middle schoolers with school computers.  

The task for management is simple. Once upon a time, central management of internet traffic mostly worked (before the days of remote working as a standard). The trick is achieving the same kind of management of internet traffic that was once centralized, knowing we can no longer rely on that central choke point. 

You start to ask “How do I do this to my employees without feeling like a principal at a school district?” After all, freedom of location includes this idea that you can achieve work without feeling like every move you make is being watched (mid-day laundry is such a nice break from the grind, right?). 

Now, possibly you realize that the problem space is split in two related but distinct asks from the business. First is content management, the harbinger of dread as you take this on, and then there are malicious threats spread throughout the internet that even the most technically savvy individual could encounter without knowing. Furthermore, it’s becoming apparent that number 2 has a lot of surface area, as it’s not just spam and malware anymore. It’s botnets, ransomware, cryptoming, crypto schemes, dark generative AI, and so on that have blossomed as malicious actors are finding more creative ways to target users (cough cough wink wink read these other blogs on just that <link>). 

Now What?

We have to find a way to protect our users from all these threats identified in ask two, while being very cautious to only apply what is strictly necessary to be in compliance with corporate policies on acceptable use (ask 1). Additionally, we need to make sure that:

• If end users are not doing anything harmful, that they aren’t even aware these protections are in place 
• That any interference with web surfing and usage is minimal and rapid so that there is not a feeling of slowness or bad wifi service 
• If in a state where protections need to be removed due to mis-categorization or impediment of work, it can be done easily and even the most tech illiterate person can fix their own issues.

How Banyan Does Internet Threat Protection

We felt that the best method to provide the best experience was to leave the heavy lifting to the DNS rather than the device. To emphasize, we decided early on that any protections and controls that were to be applied to the device when it’s surfing the web was to be done via our Global DNS servers rather than locally on the device. So that the speed was achieved and we only had to do simple management of the DNS provider on the machine, which is a time tested process. 

Because the traffic is sent to our global DNS, we moved to provide a layer of validation to each DNS request, where configurations made by admins would be checked against the devices those configurations target, and a decision is made whether or not to supply the device with the resource it requested. 

For the configurations, we purposefully called out the two asks that would come from the business. The admin has the ability to control which threats to block on a device (and which content to allow or block to adhere to the company’s corporate policy). 

Internet Threat Protection, Step by Step

Start by defining which types of threats you deem not safe for your end users. We have several threat classifications: classic threats like malware (blue), modern threats like crypto mining (gray), ways in which a person could circumvent protection which we deem a threat (orange), and we have protections for websites that have statistically high chance to be malicious in some way but have yet to be evaluated by the industry (pink). Shown below is that breakdown:

We recommend all threats should be enabled. 

To comply with corporate compliance, we allow you to select from one of over 30+ categories to block traffic from. Furthermore, you can define specific sites you wish to allow (or not allow) your end users access to. For example, if you want to block social media from your corporate devices but still allow the end users access to LinkedIn, it’s as easy as entering LinkedIn’s domain and moving on. Banyan’s Internet Threat Protection has you covered:

Every corporate policy is different; therefore, we will let you be the best judge for what content you wish to manage. 

Lastly, we provide the finely-tuned targeting that exists today in Banyan. Being able to target based on a number of factors, such as MDM management, user group, platform, and ownership. This means you will have an easy way to exclude BYOD from any policy that blocks internet usage. 

Additionally, we provide a way to message blocked individuals with instructions, giving them details on how they can engage you or your teams if they believe a block was inappropriately placed.

Once the policy is saved, the device will pick up the action to start routing DNS requests to Banyan within 15 minutes, leading to a simple and painless deployment. 

Learn more about Banyan Internet Threat Protection (available in our Unlimited Solution) by setting up a custom demo with our team.

Welcome to our release highlights blog, where we delve into the exciting world of Banyan Security and uncover the release highlights for the month of June. In this fast-paced digital era, ensuring the utmost security has become paramount. Banyan Security has been at the forefront of providing innovative solutions that safeguard organizations against ever-evolving threats, including security for AI tools. From cutting-edge technologies to insightful developments, this blog will be your guide to the new features in Banyan Security over the past few weeks.

New Features in June

More Connection Options

Mobile Tunnel:

Banyan’s mobile app now allows end users to connect to Service Tunnels in addition to hosted websites.

Learn more on connecting to service tunnels here.

Enhancing Device Trust Factor Options

• New Trust Factor: Enhanced OS Version
  • OS Versions can now be configured by the “Last x version(s)”. This frees admins from having to update the Trust Factor configuration with every new OS version release. Previously, admins had to configure and continually update specific OS version numbers.
• New Trust Factor: CrowdStrike Registered With
  • The Registered With factor validates that the device at hand is registered with the CrowdStrike environment. Registered With is derived from a CrowdStrike API endpoint.

Learn more on trust factors here.

New Features – Customized Branding

• Branding Customization
  • Admins can now use customized branding for any Banyan browser error and success pages with their organization’s own logo and brand colors.

Get the complete details on the May and June 2023 releases here or schedule a custom demo today.

In the third part of our VPN as-a-service (VPNaaS) video blog series, Ashur Kanoon takes us through a 3-minute tunnel discovery and configuration using Banyan Security.

–

In this 5-minute video blog, Ashur Kanoon takes us through VPN as-a-service (VPNaaS); see how easy it is from configuration to deployment in our VPNaaS tunnel demo.

[transcript] Welcome to the Banyan Security VPNaaS demo. In this demo, you’ll see from deployment all the way to end user experience. So first, let’s talk about how you quickly deploy this after you get a domain. The next thing that needs to be done is to either deploy an access tier or a connector. And I’m going to show you how to deploy a connector in any network you want…and how quickly it is.

Creating a Connector

So I select Create a Connector. I’ll just call it AshMacC2, and I’ll leave everything else as default. Select Continue, and I’ll go ahead and use the Docker Container install (but there is a TarBall Installer option). There’s ways to install this in Windows Server, and there are ways to install this in different cloud service providers. So in this case, there are a couple of commands to copy. I’m going to copy the first set, hit Enter, copy the second set, hit Enter, put my password. And it’s pulled all of the connector software that it needs, and it’s configured it. So we’ll see it in a second.

Let’s look at migrating to VPNaaS (VPN as a Service) and examine the benefits and considerations for migration. Watch Ashur Kanoon below as he demonstrates the key factors you should be keeping in mind (plus considerations other vendors might hide).

[transcript] So what is VPNaaS? It’s basically VPN as-a-service: something that’s hosted without having to deploy traditional VPN appliances. So what are some of the advantages? One: scalability. VPN as-a-service allows organizations to quickly and easily scale up and down without having to buy, rack, then stack hardware. It’s also cost-effective. You don’t need to buy the hardware, the licenses, you don’t have to buy, then rack, stack… It’s all in the cloud for you. You just have to basically configure and typically support is bundled in.

Access Anywhere Anytime

It’s easily accessible because usually these are cloud-based, so they’re deployed everywhere. You can access them from anywhere you want. And there’s also typically POPs in China for organizations that have offices there and need to get past the Great Firewall. There’s also easy management; so with VPN as a service, there’s typically a central place to administer the whole infrastructure, and this just frees up IT resources to do other tasks. From a security perspective, with VPNaaS, there are usually more robust security measures. Think about what you have to do today for the VPN appliance…from a firewall perspective, all of that stuff is taken care of for you, and when deploying updated ciphers, all that stuff can be done without having to upgrade or install any FIPS modules or anything like that.

Ultimate Flexibility in Deployment

VPNaaS is also very flexible, meaning there’s a wide range of options and configurations. It really allows you to deploy this as you wish in many different places. In terms of deployment: rapid deployment is also another huge benefit to VPNaaS. Typically you can get VPN as-a-service system up and running in minutes. These can be deployed using like virtual appliances in marketplaces or just a few sets of commands that run on your standard Linux boxes. Now let’s take a look at some considerations when migrating. So the first one is the network architecture. You can basically deploy a VPN as-a-service in many different ways. A lot of times, most of the components are cloud-based, and then there might be a connector that you have to deploy…and these connectors can run anywhere: on-prem, or in your cloud service provider.

Be Mindful of Bandwidth

You should also think about bandwidth requirements. Some VPNaaS have limitations. Depending on what you want to do, you have to make sure that those bandwidth requirements can be met using something in the cloud, and you’re not going to be charged extra for bandwidth consumption. The next consideration: can the VPN as a service integrate with your existing systems? You probably have things for authentication, maybe MDM and EDR. So you want to make sure what you’re migrating to can also support that because you don’t want to have to take a step back.

Compliance Considerations

Don’t forget data privacy and regulations: if you are in an industry that requires some compliance, you want to make sure that data is stored where you think is best, and you also want to make sure that your corporate data isn’t being decrypted, analyzed and then re-encrypted. This is often happening with organizations that are SWG-led, meaning they initially had a SWG (and they decrypt all the traffic). You also want to make sure that the VPN as a service has a client or agent on the platforms that you are using today. Sometimes you’ll see that the new offering is desktop only or it’s missing [for example] a Linux application or agent. You want to also make sure that the new VPN as a service has some training. Typically, these should be very easy to deploy, but in some cases they’re not. You need to train your IT team so that they can deploy rather quickly, and in the scenarios where something happens, you also want to check on support. Some organizations have requirements for in-region support.

Banyan Security is here to make migrating to VPNaaS easy to deploy in your organization – schedule a custom demo today to see how quickly we deploy.

Let’s keep this super-simple: the devil is in the details in any disclosure policy. If you go to the OpenAI ChatGPT FAQ, there are a few points that should raise the eyebrows of any security engineer trying to protect company data and access. To that purpose, at the end of this blog, you’ll find three ways to opt out of ChatGPT data sharing that will help you and your CISO sleep better at night.

Let’s assume your company has allowed ChatGPT for employee use. Now, let’s take a look at the terms of use for ChatGPT:

Will you use my conversations for training?

• Yes. Your conversations may be reviewed by our AI trainers to improve our systems.

From their privacy policy:

We’ll retain your Personal Information for only as long as we need in order to provide our Service to you, or for other legitimate business purposes such as resolving disputes, safety and security reasons, or complying with our legal obligations. How long we retain Personal Information will depend on a number of factors, such as the amount, nature, and sensitivity of the information, the potential risk of harm from unauthorized use or disclosure, our purpose for processing the information, and any legal requirements.

Did you notice the retention period of the data seems a bit vague? To be reductionist: any conversation you have (or the corporate you, through your organization’s SSO) gets to be retained in perpetuity by OpenAI. So all of those questions and shortcuts AI has helped with could easily come back to bite your company in the future, depending on what you told ChatGPT in the first place.

Here are a few thoughts for staring at your ceiling at midnight:

• Attackers probe ChatGPT for target data like passwords, APIs, or other intellectual property. Crafty prompters know how to get the AI to relinquish this data, and yes, they’re likely trying to get it on your company for any vulnerabilities they can exploit.
• Incorrect data is difficult to purge (including data on people), leading on Italy’s ChatGPT ban – so enter information at your own risk.
• Be careful what you give the world – you don’t want your competition finding code, schematics, ideas, or plans from your organization. Samsung recently found this out when one employee asked ChatGPT to check confidential database source code for errors, another employee generated code optimization, and a third fed a company video meeting into ChatGPT to summarize meeting minutes. The data shared by all three employees came back to hurt the company. Let’s not put company information into an intelligent system that’s built to learn, right?

Three ways to opt out of ChatGPT data sharing

There are three ways to opt out of ChatGPT data sharing that can keep company data incognito:

• Use the API, whose terms clearly state: “We do not use Content that you provide to or receive from our API (“API Content”) to develop or improve our Services.” It may be less convenient (especially on mobile), but it’s a step worth taking…
• Set up a secure instance through Microsoft Azure.
• Submit this opt-out form for your company.

1. 1. Enter your email.
   2. Find your OpenAI Organization ID [below]
      1. Go to this page and log in.
      2. Select the “Settings” tab and find your Organization name and ID per below:

         

   3. Copy the Organization ID and name.
   4. Paste them into the form described in step 1.
   5. Hit “Submit.”

Speaking of reading the fine print, have you wondered what the Banyan privacy policies are? We’re glad you’re curious and welcome you to read further.

Corporate employees are often required to do work that involves using publicly-accessible resources (e.g., Salesforce or a staging website), which go beyond the bounds of private network control. In light of the need to connect their workforce to these public SaaS applications, many organizations recognize the need for better security, visibility, and flexibility than legacy VPNs can offer. In other words, organizations want the security of a modern cloud VPN with continuous authorization throughout user sessions, as well as the flexibility for employees to work on public applications. So how can a Service Tunnel help?

This is where Banyan Security’s new cloud VPN feature comes in handy: Service Tunnel (our modern VPN as a Service) can now secure public resources based on domain or IP.

In this blog, we’ll explain how this works and how you can set up a Service Tunnel to provide your users a secure path to Salesforce.

The challenge

• Orgs require employees to use public resources (like Salesforce), but they have no way to ensure the security of their employees’ usage of these apps beyond the single authentication check that occurs during login.
• Lost or stolen credentials can be used to access public SaaS applications, putting the integrity and availability of sensitive organizational data at risk.
• Public SaaS apps have no authentication or continuous authorization built in; admins need to configure IDP integrations.
• Legacy IP whitelisting techniques require admins to manage large lists of continually changing employee source IPs.

Banyan’s Solution: Service Tunnel for Public Domains

In addition to routing traffic to your private networks, Service Tunnels can route public traffic destined for the internet. Internet traffic routed through Service Tunnel(s) uses the source IP of a Banyan Access Tier (the brain of Banyan’s product; a reverse proxy).

Admins can then IP whitelist to restrict user access on login and throughout a user’s session on a SaaS platform.

How to securely connect to Salesforce using Banyan

Here, we show how to use a Service Tunnel to route to multiple Salesforce subdomains:

1. Register a Service Tunnel with Banyan, and configure it to route to public domains;
2. Set IP whitelist rules for your users in Salesforce; and finally,
3. Connect your Service Tunnel in the Banyan app, and securely access Salesforce.

For an in-depth guide on how to connect to a public SaaS service, like Salesforce, using Banyan, check out our Salesforce solution guide.

With Black Friday and Cyber Monday out of the way and the holidays right around the corner, IT folks are preparing to get the usual “new device” calls and helpdesk tickets. With over $9B spent on Black Friday itself, you can pretty much guarantee some of your co-workers got a new computer or mobile device. While bring your own device (BYOD) isn’t a new concept, enabling BYOD boosts employee productivity in several ways. The days when corporations would flatly ban the use of non-corporate-issued devices due to compliance reasons are waning, as most have seen the advantage of allowing users to bring their own devices and using them quickly and naturally at work.

Devices can be categories in two groups:

1. Registered Devices are desktops (macOS, Windows, Linux) and mobile devices (iOS, Android) that have a Trusted Device Certificate in their keychain. These devices have been enrolled in the system and the organization/zero trust solution is aware of them. The Trusted Device Certificate also has information about the identity of the user that has enrolled the device, allowing for user and device identity to be part of the authentication and authorization equation.
2. Unregistered Devices are desktops and mobile devices that do not have a Trusted Device certificate in their keychain. They may be unknown devices, especially the first time they are used.

Notice that we are not necessarily saying that an unregistered device is untrusted. We take a look at how unregistered devices can become “trusted” while on the path to becoming fully registered devices.

Organizations should have the ability to whitelist devices and then allow for self-service so that an end-user can get to corporate enrollment services or to specific services that are behind an identity-aware proxy. The whitelisting is accomplished by using the known, public IP address of the device. An end user can access sites like whatismyip.com and send their public IP address to an administrator. The admin will add the public IP address to the whitelist which will be used by security policies to allow this end user access only from that specific public IP. The addition of this IP address to the whitelist should ideally be temporary; to provide access to a resource while still “unregistered”, and being removed from the whitelist immediately afterward. We’ll discuss the benefits of registered devices later.

With the whitelist in place, the organization has the above option to enable the enrollment service access as well as the ability to create custom redirects to other services. These services may be for the enrollment with an Identity Provider (IdP) or multi-factor authentication (MFA).

Moreover, some lower-risk services, may be made available for registered and unregistered devices based on a granular policy. Both types of devices will be visible to the administrator, along with the associated user.

Enabling self-service to specific IP-source devices means enabling productivity quickly and will help most users avoid having to call IT to get help with new devices. As a best practice, you should always create policies that ensure that medium and high-risk resources are only accessible from known, registered, healthy, and compliant devices regardless of if they are BYOD or corporate-issued.

The ultimate goal should be to have all devices be registered, with the ability to allow unregistered devices as a pathway to that goal. Why? For the end user, having a registered devices means possibly getting access to additional resources that help them become more productive. Also, the Banyan app provides a Service Catalog that lets them know exactly what resources they can access. For the organization and the administrator, there are more possibilities for visibility and policy enforcement of those devices. Also, with our Remote Diagnostic functionality, which is built-in to the Banyan app, the admin can quickly address issues that may come up without requiring the end user to do anything to help in the troubleshooting.

To schedule a demo and see how easily you can support BYOD, visit https://www.banyansecurity.io/demo-request/.

Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft which provides a user with a graphical interface to connect to a Windows-based computer over a network connection. The user employs RDP client software for this purpose, while the other computer must run RDP server software. Browser-based access is also supported, eliminating the need for client software, though it does require an RDP to HTML5 broker. Securing RDP takes a few steps, which we will outline below – and of course having a simple SSE product like Banyan reduces complexity.

To access Macs, Virtual Network Computing (VNC) may be used. VNC, developed by Olivetti & Oracle Research Lab at Cambridge in the UK, is a graphical desktop-sharing system that uses the Remote Frame Buffer protocol (RFB) to remotely control another computer. By default, RFB is not a secure protocol. While passwords are not sent in plain-text (as in telnet), cracking could prove successful if both the encryption key and encoded password were sniffed from a network. Many flavors of VNC exist, including free versions.

The following protocols and ports are used, and thus need to be protected:

• RDP
  • TCP
  • Port 3389 is used for internal (LAN)
  • Port 3390 is for external (WAN) connections
• VNC
  • TCP
  • Ports 5900, 5800 and 5901 for multi-monitor

Another related technology is Virtual Desktop Infrastructure (VDI). VDI refers to the use of virtual machines to provide and manage virtual desktops. VDI hosts desktop environments on a centralized server and deploys them to end users on request. Popular VDI solutions are available from Citrix and VMware and they have client and client-based methods to access them.

RDP servers may be accessed directly or over a Virtual Private Network (VPN). RDP sessions can use free clients such as Microsoft Remote Desktop. RDP can also be accessed over HTML5-enabled browsers using free, open-source software such as Guacamole. In actual practice, the Guacamole server is typically made accessible behind a firewall and accessed using a tunnel-based VPN. Unfortunately, such approaches suffer from poor performance.

Quick tips for securing RDP

Here are some tips to secure your RDP Server:

• Hide the server
  • First security rule of RDP – it is absolutely unacceptable to leave RDP exposed on the internet for access – no matter how much endpoint and systems hardening is performed. The risks of such exposure are simply far too high. RDP is meant to be used only across a local area network (LAN).
• Lock down the server
  • Locking down the server itself vs. locking down the access. Be sure that no other services are running on the same machine. Be sure to enable windows (and macOS) firewalls allowing access only from the LAN IP-address range and only to the ports required. Enable activity logging and check it often to ensure that users are not attempting anything they shouldn’t be. It may be best to disable persistent sessions.
  • RDP may be enabled on standard end-user machines and also those running RDS. Using standard end-user machines is not preferred and will make it harder to monitor usage.
  • Be sure to upgrade the server and OS often. Many CVEs exist for RDP. Running a quick CVE search at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RDP returns 104 CVEs for FreeRDP, Windows Remote Desktop Protocol (RDP), and other flavors.
• Pick an access method
  • With some solutions, two methods may be available: tunneling traffic for RDP and proxying. Each has advantages and disadvantages. With mTLS (mutual TLS), proxying is an option that adds connection-level security onto a standard RDP connection. If tunneling is preferred, be sure to enable granular access to ensure the best end-user experience. Be sure to configure idle timers to ensure that inactive systems are quickly logged out.
• Authentication and authorization
  • All users should be authenticated. Under no circumstance should generic users be allowed. Generic user accounts make it hard to authorize what a user should do and impossible to know who was signed in if there is a security event.
  • Enable MFA (Multi-Factor Authentication) at the access and system level, if possible.
  • Check that access is coming from a known system and determine the system’s trust by enabling device identity and trust features. Organizations may decide to give full desktop access to compliant devices and single-application access to non-compliant or unknown (3^rd party) devices.

To learn more about how Banyan can secure your RDP infrastructure and schedule a demo, visit https://www.banyansecurity.io.

How do system admins protect their company’s sensitive data, which is hosted in multiple environments and accessed by employees and contractors in changing locations?

This is what Banyan’s ZTNA solution allows admins to do. And now, we’ve made it even easier for admins by streamlining the steps required to install the brain of our ZTNA solution: the Access Tier.

Here, we’ll explain what our Access Tier is, what it does, and how easy it is to install one in your organization.

What is an Access Tier?

The Access Tier acts as the data plane of Banyan’s ZTNA solution; it works in conjunction with Banyan’s Cloud Command Center, which can be thought of as the control plane, where admins can centrally manage security policies and events in their org.

Technically speaking, the Access Tier is an identity-aware proxy (IAP) that securely mediates access between entities on the internet and internal services. Each Banyan Access Tier has a public IP address that is reachable from the internet and able to accept inbound connections. Banyan’s Flexible Edge architecture allows customers to deploy an Access Tier inside their private network on their org’s own private server (aka Private Edge) if they want to manage the data plane or they can alternatively opt to have Banyan manage the Access Tier (aka Global Edge).

Introducing a streamlined, self-serviceable installation flow

In our November 2022 release of Access Tier v2, we introduced a guided installation and configuration flow. Now, only three simple steps are required to launch orgs on their zero-trust journey:

1. Configure – Here, admins define the list of private CIDRs that will be exposed (via the Access Tier) as well as any domains that will resolve via private DNS.
2. Install – Installation methods (Docker Container, Tarball Installer, Deb/RPM Package, AWS CloudFormation, and even Terraform*) are now available selections in the new installation flow, and steps required to complete installation are embedded right into the Cloud Command Center’s UI.
3. Validate – In this final step, admins can ensure that they’ve successfully established end-to-end connectivity from devices to private resources within the network.

*P.S. Here’s a secret tip…

If you want an unbelievably fast and easy deployment experience, try installing the Access Tier using the new Terraform module – this leverages Infrastructure as Code and doesn’t even require use of our Command Center’s UI. With Access Tier v2, this method brings substantial cohesion to the overall deployment process, and it requires minimal parameters.

Centralized manageability from the Cloud Command Center

Managing Access Tier settings and configurations, post-installation, has also been shifted to Banyan’s Cloud Command Center. This allows admins managing their own org’s Access Tiers, or MSPs managing their customers’ Access Tiers, to do so from a central, highly visible location.

Access Tier Advanced Settings

Hopefully I’ve shown just how easy it is to deploy Banyan’s ZTNA solution. To learn more about the Access Tier, visit here.