No compromises
This should be understood both ways.
ZafePass is built up around a simple yet extremely effective architecture of transit gateways or proxies, between the ZafePass client and the gateway the SSH2 protocol is used, which in it’s own right makes the communication virtually impossible to eavesdrop on.
The ZafePass Authentication and Provisioning backend is a Windows service, it can however be run under Wine on Linux if you don’t like the idea of having Windows servers in charge of your critical infrastructure.
ZafePass itself does not rely on any 3rd party services to verify the identity of the users, but does provide integration to 3rd party providers such as SMS gateways for SMS OTP and Active Directory for those who prefer.
Uncompromisable
FIPS140-2
The design of ZafePass is based on many years of work and also on previous implementations or generations of the platform.
Back in the day, when we developed the first generation of ZafePass, it was a focus point back then to have our design and method externally validated, to adhere to the highest standards of secure data processing. It took a lot of time, effort, documentation and money of course, but we finally got the methods and implementation FIPS140-2 validated, by the standards of the time it was amongst the highest level of certification one could achieve.
What we did not foresee back in those days, was the the certification only relates to a specific compiled and signed binary, embodied in a .dll, so every time we made any change that would require a recompilation of the validation stack, that would prompt a new validation, so needless to say that we kinda abandoned that train back then..
But
The design of the MFA security policy engine and the method for verifying the user’s identity are absolutely inspired by what we developed back in those days and got a blue stamp on.
Hackers, crackers and hijackers
We have over the course of developing ZafePass, which at this time of writing encompasses more than 12 years of work on the current generation, had a great companionship with a lot of hackers across the world, who have done their absolute best to find any way of hacking their way through the ZafePass gateways, or try and device a way of subverting the back-end, none of them have been successful – not even once.
You see, you always communicate through a ZafePass gateway, that gateway only speaks SSH and does not provide any other means of communication, to communicate with it you do not only need a username and a password (which by the way is not the same as any of the usernames of the users) but also a private key.
So, even if you had access to the most advanced Quantum computer, you would still need to guess a working combination of a login, a password and a private key, none of which is ever supplied by the user and is not built into the client either, those secrets are supplied by the ZafePass backend to the client after the user completes authentication and are stored encrypted in memory, encrypted with a random per-session key by the way.
So keep on guessing, hacking an SSH server is not trivial, they are the foundation of secure communication with almost any flavor of Unix, so that particular piece is being kept a real close eye on, failing here would probably break the internet.
When a user is authenticated, the client assembles a lot of information about the local environment, data about the host computer hardware, the Operating System, the network and so on, data a remote attacker would never have a chance to obtain. Then all of this is forwarded, over an encrypted tunnel through a logon gateway, to the ZafePass Authentication and Provisioning back-end, but not knowing what the rules defined for this particular user is, thus also having no idea what the correct dataset is to comply with the rules defined in the MFA security policy engine.
When successfully authenticated, the user’s ZafePass client receives a list of available targets, all the gateway groups needed for those targets and the gateways in those groups, plus the authentication credentials needed for authenticating against each gateway, they are machine generated and have no connection to the user or the user’s credentials, this is also stored encrypted in memory.
Why go to this trouble ?
The less we can give a hacker or intruder to go on, the less likely they are to succeed.
So far it seems to be doing something right…
Many have tried to hack our system, we are examined and probed hundreds if not thousands of times a day, none of that ever amounts to more.
We have also encouraged many a bounty hunter, pen-tester, ethical or unethical hacker to unleash hell on the system, some we even supplied a working ZafePass client including the site identity, but they too gave up.
Truthfully, even reverse engineering the client will reveal nothing that could be used to orchestrate an attack, all the metrics that is being used to validate a user and the user’s identity is validated at the remote end, which many have also realized in the process and until the remote provisioning system supplies the client with information about available destinations, the client know nothing about what’s potentially available.
External validation
In order to have someone externally from us perform a thorough examination, pressure test and analysis of what we do and how we do it, we teamed up with an accredited and well respected partner, who over the course of 10 months both documented our process and analyzed our methods.
They did come with a lot of recommendations for improvements, most of which we implemented, but given that we don’t do it the same way as everybody else because we don’t follow best practice, we had a lot of discussions back end forth.
We don’t follow established best practices for everything and we don’t do that because we wish to do something that is above and beyond what was currently possible, that means that we had to think out of the box a lot, turn the box upside down and inside out.
Despite our friendly fights over methods, they had to admit that even though we don’t follow best practices, there was no practical way they could device any method for crafting a compromise either, not even in theory.
No backdoors and no government access
In a new ZafePass installation, no encryption keys or certificates comes with the installation, in fact – ZafePass does not use x.509 certificates at all.
The use of x.509 certificates, the standard website certificates, the ones that are signed by a CA, which in turn have their certificates signed a higher level CA, is based on convenience and practicality, in our humble opinion.
The entire PKI infrastructure with inherited trust is the only real practical way of knowing that a certificate on a website is legit or is just someone claiming to be amazon.com for example, with a mechanism for verifying the validity of the signatures on the certificates, man-in-the-middle compromises can be avoided.
ZafePass doesn’t need that.
ZafePass make heavy use of public/private (asymmetric) key encryption (PGP/RSA/ECC) and pre-shared keys, a fresh ZafePass installation generates all it’s own encryption key-pairs, the public key needed for validating the authenticity of the Provisioning server is included in the site identity file.
This means a couple of things, most importantly – neither we at Zafehouze nor anyone else have any knowledge of the key-pairs used by your installation, so regardless of we wishing to gain access to your installation or not, we can only get access if you provide us with access.
Secondly it also mean that no matter how much any government, intelligence agency or criminal organization tries to convince us to provide them access, we have no way of doing so and finally, even if someone broke into our offices and stole everything, there would be nothing to give them leverage..
ZafePass MFA
ZafePass validates it’s users by not only credentials, but a multitude of other parameters and environmental properties of the user.
Firstly, a user can only log on from a device that have already been approved, if the device is unknown to the system the device information is queued and needs approval, this approval can be manual or automatic.
Then the user’s credentials are validated.
If the user is known to the system and the credentials can be validated, one or more environmental properties can be used as the base for allowing the user access, that could be the public or private IP address of the user, but it can also be the machine serial number or the MAC address, information that is virtually impossible for the casual man-in-the-middle to obtain at a distance.
If all this passes inspection, a list of available resources are compiled, where also the time of day, day of the week, network location, device used and many other parameters are taken into account, depending on the rules defined in the policy engine, can add resources available to the user or limit what the user can have access to, depending on where they are and what equipment they use.
One of the main advantages of this MFA policy engine is also, that it can actually replace the use of currently used 2FA methods such as Authenticator and SMS pin-codes, also to the advantage of the user, since the user does not have to do anything.
Technically speaking..
An Authenticator verification does only establish knowledge of a secret, that secret and current time together forms the 6 digit rolling pincode. The Authenticator app is usually on a phone, so by proxy passing Authenticator verification proves possession of a device that have information about a secret.
Similarly, a SMS pincode proves possession of SIM card and knowledge of the optional pin-code used to unlock the card.
Using the Device-ID of a USB storage device with the ZafePass client on proves more or less the same, possession of a device that is separate to the user’s computer.
So, for scenarios where using traditional 2FA OTP methods are not possible or desired for practical reasons, the ZafePass security policy engine can provide the same level of 2FA or better.
Transit gateways / proxies
The transit gateways in ZafePass is based on FreeBSD UNIX, a free and Open Source PC Operating System first released in 1993, FreeBSD is based on an Operating System developed by the Computer Systems Research Group (CSRG) at the University of California, Berkeley. BSD was first released in 1978, it began as an improved derivative of AT&T’s original Unix developed at Bell Labs, based on the source code.
Today, FreeBSD is used by many IT companies such as IBM, Nokia, Juniper Networks and NetApp to build their products. Certain parts of Apple’s macOS operating system are based on FreeBSD. Both the PlayStation 3 and Nintendo Switch operating system also borrow certain components from FreeBSD, while the PlayStation 4 operating system is derived from FreeBSD 9. Netflix, WhatsApp, pfSense firewalls and FlightAware are also examples of large, successful and heavily network-oriented companies which are running FreeBSD.
[Source: Wikipedia]
FreeBSD is not as user friendly as Linux by a long shot and configuring such a server is by no means trivial if you are not familiar with it, so what we have done is automating the deployment, configuration and management of the gateways, so all you as the system owner have to do is make a basic installation of FreeBSD with more or less the default settings, make a few modifications to allow the Synchronizer access to it and ZafePass does the rest.
You can even make a standard gateway image, with the few modifications needed and use that as basis for deploying gateways in your infrastructure, making it extremely easy to scale and expand your ZafePass solution.
Peer-2-peer
When a user logs on to ZafePass, the user’s identity is verified and the user’s client receives a list of the available systems, then the client closes the connection and goes to sleep, or null-state as we call it.
When a user requests access to a system from the list, a connection is established directly from the client and to one of gateways in the group providing access to the that particular network segment, not through the central gateways like a VPN would.
The real advantage here is first and foremost the lack of need to maintain a network infrastructure providing routing to all the remote segments, no double load on the internet connection of the main installation and also not the delay either. Imagine you are sitting at the company’s satellite office in Singapore wanting to connect to a local data center also in Singapore, your communication should have gone to London first and then be routed back to Singapore, that makes no sense at all.
A secondary but not less important detail in the type of system architecture is, that if for some reason someone managed to break in to your office in Singapore (either physically or by local network compromise), they can’t use the VPN or routed infrastructure to sneak into the headquarters from what is supposed to be a “trusted” network, this type of compromise is not at all as uncommon as you might think.
This is why we call it “Data islands“, there is no data flow between the islands, thus also preventing lateral movement in the network, any compromise/malware/ransomware that could affect a segment can’t move on to anything else.
Gateway groups
ZafePass is designed for today’s distributed infrastructure, where you would have servers or services directly available on the network of the company, some servers with Azure, some with AWS, maybe a satellite office or twenty, that can all be managed in ZafePass.
In ZafePass, networks are divided into segments, a segment (or data island) is a network where the servers can communicate with each other, that network segment can be one or more devices.
The servers in this segment may or may not need access to the internet, if they do they should have it’s own NAT firewall, protecting the servers on that network segment against any incoming intrusion and there should be no forwarding of inbound connections from the outside.
The ZafePass gateway(s) responsible for that segment is then configures with two network interfaces, one connected to the outside network and one on the inside. The gateways are NOT routers and DO NOT route network traffic, they are proxies acting on the user’s behalf in the network, establishing a connection to the exact endpoint the user’s application need to communicate with, shielding everything else.
All gateways providing access to the same network segment are added to the same group in ZafePass, there is virtually no limit to the number of gateways you can have and also no practical limit to the number of groups you can create, thus also no limit to the number of network segments you can provide access to either.
(Disclaimer: Of course there is a limit, the actual limit is 2^63-1 or 9,223,372,036,854,775,807 gateways and groups, but it’s highly unlikely anyone would ever reach it, even if a gateway and corresponding gateway group is defined for every electronic network enabled device on the planet)
Firewall, ACLs and remote logging
All ZafePass gateways have their own Firewall built in, this firewall also helps the gateway preventing attacks by for itself not exposing any secondary attack vectors that could lead to compromise.
The Synchronizer continuously updates the firewall ruleset and ACLs on the gateway, if enabled it will even create and maintain per-user firewall rulesets with optional logging that will log each connection from a user to a destination, that way all user access to any system in the segment can be logged.
ZafePass also have integrated management of rSyslog on a per-gateway-group basis, including RHEL (transaction-aware logging, so you never miss a log entry) and certificate management, enabling near real-time logging to a central SIEM or log server, for a near real-time view of any activity in your installation.