Benefits of using ZafePass

Zafehouze is among the leading implementing the True Zero Trust Architcture and our ZafePass solution takes connectivity to an unmatched level, enabling both onsite and remote users including 3rd parties to rapidly and securely connect to only their entitled resources in their workspace.

ZafePass provide IT full control of any aspect of the solution from the user attributes to security policies on both group (site) and/or user level.

ZafePass is a unified solution, designed with user simplicity in mind, for securely accessing any IT/OT/IoT resource, leaving cyber attackers and adversaries unsuccessful in their attempt to compromise the ZafePass protected resources.

Zero Trust has become an industry buzz-word often used by vendors re-routing client-data traffic over their infrastructure and further has 3rd party dependencies to other point-security solutions like PKI, VPN, Identity Management etc.

ZafePass is NONE of that..

True Zero Trust Architecture

Quoting from the NIST SP 800-207 publication: Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.

What does all that mean ?

In short, it means that your systems should not trust anything, no matter where in the network it is, no user or device should be trusted until the identity have been verified.

ZafePass have an advanced identity management engine (IAM) that utilizes more than just the user’s username, a password and an optional 2FA like Authenticator or OAuth for determining the user’s identity.

In ZafePass, also properties about the operating environment of the user is used, so information such as the CPU serial number, the MAC address or the drive used for running the ZafePass client from are suddenly a token, a unique piece of information that is readily available to the client, but completely impossible for a man-in-the-middle or impersonator to obtain.

ZafePass is 100% a software solution, downloadable and deployable within hours, so you can take full advantage of (and deploy in in) your current private cloud or virtualization infrastructure.

ZafePass runs equally fine on virtualized as well as physical machines and our transit gateways scales very well both up and down, so you can use a Raspberry PI as a gateway for access to resources with a small number of concurrent users or where performance requirements are relaxed, but does also support massive 256 way servers with memory in the Terabyte range, all depending on load requirements.

While the ZafePass backend is running on a Windows platform, the gateways support a wide range of hardware, from small credit-card size ARM devices (such as Raspberry and Rock64), over all x86, arm64, armv7, aarch64, arm64, powerpc, powerpc64 and risc64 architectures, so capable hardware is certainly within almost every budget and implementation requirement, also making it a lot easier to find replacement hardware should the production systems break (and they do).

ZafePass is installed in your infrastructure, running on equipment 100% owned and managed by your engineers.

In this case, on-prem is in it’s most relaxed definition, you can absolutely install it running within AWS, Google Compute or Azure, if that is what you need, but it’s 100% under your control.

In fact, when a ZafePass installation is deployed the first time, all encryption keys, keypairs and similar that it needs are generated on a per-installation basis and we have no knowledge about how your system is configured.

The big advantage by us not having any information about or any access to your installation is that there’s nothing that can be obtained by anyone, by subversion or malice. The Intelligence community can come running to us all they want, we don’t have anything we can give them, regardless of whether we want to or not.

Your installation is yours.

In any network segment, the servers and systems there expose not only the service ports for the services they provide, they also expose a whole lot of secondary services that are, for the user, completely unrelated to the service they provide.

Take a MS Exchange server for example, it exposes not only the IMAP and SMTP ports, also all the service ports for Windows networking is exposed, RPC, probably a webserver and a lot of other potential vulenrabilites.

With ZafePass, ONLY the service ports related to the specific service available to the user are being exposed, so for this argument’s sake, only the IMAP and SMTP ports, everything else is shielded.

From a network perspective, all servers in the ZafePass protected segment simply vanishes off the network, so any adversary or attacker will have absolutely no clue as to what is available in the segment or that there is a protected network segment at all.

Where a VPN only can provide a coarse access control on the network level, ZafePass provides access control on the service and application level, further limiting the scope of any potential data breach.

In ZafePass, even if a user have access to hundreds of systems, access is only made available when the user invokes the menu and requests access to a specific system or service, when the user is done using the service and closes the application, ZafePass removes the access pathways and any access to the remote service is closed.

This type of behavior is called ephemeral connectivity, where an applications ability to communicate with the remote systems is only temporary, it’s removed when it’s no longer needed, further reducing the potential attack surface.

The practical actions surrounding on-boarding a large number of users are few and it’s easy, depending on your security requirements of course.

All users can download the generic ZafePass client from the intranet, the site identity identifying the installation can be send by email, where IT can supervise the adoption and make more specific and tailored access rules where needed.

For high-security environments, adoption of a user into the ZafePass ecosystem can be done in minutes, while the user is on the phone and have effect immediately.

There are no problematic drivers to install and no certificates needed, so after deployment of a user it quite rare to ever needing to support them with ZafePass, unlike VPN where it can be a common occurrence having to wait in queue for an engineer to remotely fix the VPN client.

ZafePass have it’s own fail-over / fallback and load-share systems built in, so if a gateway for some reason does not answer or is overloaded, another one in the group will automatically be used instead.

ZafePass is compatible with probably any load-share, load-balancing and fail-over solution in the market, from DNS round-robin over various clustering methods to BGP4 re-routing, for those with requirements above and beyond what is in ZafePass.

ZafePass also supports HA implementations of the back-end Authentication server, where series of Authentication servers can be allocated to specific groups of gateways handling logon, supporting both hot standby and cold standby infrastructure.

ZafePass scales, vertically and horizontally so to say..

ZafePass transit gateways are ordered into groups, where the gateways in any group is assumed to provide access to all the same targets, so a gateway group represents in reality a network segment..

Those network segments can be anywhere in the network or on the internet.

So you can have your installation on-prem with 2 secure “data islands” in the main network, then have a segment defined in Azure Stockholm, one in Azure San Fransisco and one securing a rack you have hosted in an undisclosed data-center.

The users have no knowledge of where the network segments are and does not need to configure anything, in fact, the users can’t configure anything related to resources available, all this is handled by ZafePass, based on the resource assignments you have defined.

ZafePass can synchronize it’s resource menu assignments with MS Active Directory, so a user is assigned access based on their AD group memberships, additional memberships can be both granted and revoked based on the PAM policy engine rules.

When first configured, ZafePass more or less manages itself, based on which AD groups they hold membership of, ZafePass’ background synchronizer makes sure all transit gateways are kept updated with who have access to what at all times, completely automatically, so a single network engineer can easily manage a ZafePass installation with thousands of users and any number of network segments or data islands.

In terms of access, there is nothing a user can configure, it’s all done automatically.

Also, ZafePass does not rely on drivers or traffic capture, require only user permissions to operate and does not even require installation, so a user could carry the ZafePass client along on a USB storage device and it would work just fine.

ZafePass data transport is done based on a dual reverse-proxy VPC engine, so a user can be connected to not only any number of network segments at the same time, even if those segments have the same IP address scope, but a user can also be connected to two or more ZafePass sites at the same time, accessing services on all of them at the same time, without any risk of data leak or cross-contamination, the network segments the user is connected to can not “see” each other through the ZafePass client.

So, unlike VPN especially and other solutions where it depends on network data routing, filtering or capture, ZafePass does not rely on drivers and a ZafePass very rarely break, minimizing both the inconvenience for the user in having to wait for support staff resolving their connectivity issues and being delayed in their work for the same reasons..

When a ZafePass client needs to have access to a resource, the ZafePass client connects directly to one of the transit gateways in the group, this eliminates both the delay that occurs when connecting to a central site and then the data is routed though the infrastructure, causing delays and unnecessary network load, but it also makes it possible for the user to connect to a resource even if the connection to the central site is slow or unstable.

ZafePass itself is not very sensitive to network disconnects or lack of coverage when running over mobile networks, if the connection is broken it simply reconnects. If the application tunneled through ZafePass also supports disconnects or automatically reconnects upon connection loss, at most the user may have to simply reload the browser window or press “reconnect” in the application.

Can ZafePass be used via WiFi on planes, trains or when driving in a truck connected via the cellular data ?

Yes, absolutely.

Does the user need to keep logging into ZafePass ?

No, it’s all handled, it’s part of how ZafePass is designed, it’s designed for disconnects and unstable network connections..

ZafePass have a quite advanced and flexible deployment engine built-in, with an automatic configuration file editor, that can easily modify all text-based configuration files, so the application can connect to the remote system without the user having to know or do anything..

When a user requests access to a remote system, sometimes the user needs a specific application that is not necessarily part of the standard installation on all user workstations, or it can be so highly specialized or vulnerable that it’s considered a potential security or privacy breach having it permanently installed.

What could that be ?

It could be a 3270 Terminal Emulation package for accessing a mainframe for example.

Are those still in use ?

Oh yes, very much so and with ZafePass the 3270 Terminal can be deployed and configured completely automatically, granting access to the mainframe and when the user is done it cleans up everything, so it looks like the application was never there.

This can also be used by the diplomacy or C-level executives on the road, they may have a laptop but on said laptop are absolutely nothing confidential, it serves only as a secure trusted platform for accessing the company infrastructure.

So if the equipment is examined in customs, there is nothing of value.

If the laptop is stolen, there is nothing lost other than the hardware, no business plans, no diplomatic documents, no-one can steal something that isn’t there..

It can also be something less exotic of course, such as configuration files for already installed applications. A good example of this is Remote Desktop, where access to Remote Apps require using a .rdp file, simply because defining a Remote App is not possible in the Remote Desktop Client as a command line parameter or otherwise, so enabling the users to access Outlook as a Remote App for example, that’s quite a bit of a challenge..

That’s where deployment engine can also be very useful.