Tampering Visibility by Tempered Networks Airwall Solution

“Personal Note: Ok, this post has been lying around in my draft for quite some time. Sorry for that Tom, Ben, and Tempered. Too many reasons but one of them is also that the folks at Tempered were so kind to allow me a trial for a few months. I will share my experiences in a few posts to come. “

I don’t know if the organizers of Security Field Day 3 did this on purpose, but it looks like they kept a very innovative solution as encore with Tempered Networks. Their presentation was the last one in the line-up and presentations. And since I hadn’t heard about their company name, I looked them up in advance and was intrigued in how they could twist the tale on security without visibility. Todays common sensus in security is that you need to see and know what is happening on your network; Tempered says: what you cannot see, you cannot hack.

Personally I think their solution originated from the IoT/OT network environment where applying security to IoT devices is well, near impossible. The S of security is lacking in IoT for a reason. I can assure you, also from my own environment, that many IoT/OT devices do not follow RFC’s completely, let alone implement IEEE standards like Port-Based Network Access Control (IEEE 802.1X). Their paradigm is that if you place one or more sensors of such an OT network behind a device that basically hides / blinds them from the rest of the IT network, and create an overlay to wherever you have servers they need to connect to, again protected by either a hardware device or software, the communication between the two endpoints is both secure and hidden. Those ports, with often unencrypted traffic, are just not available to the generic IT network and thus less prone to intrusion events.

Their solution consists of Airwall agents that run on almost any client OS (ok, ChromeOS is a different story for any client) , hardware solutions (called gateways with also added functionality), Airwall Server agents that you can run on server OS like Linux, and a conductor from which you manage the clients and settings. Secure tunnels are created between two airwalls if traffic is allowed and defined in the conductor. That is quite similar to SD-WAN solutions or VPN solutions, isn’t it?


However, there is a big but in here too. Airwall gateways can also act / be configured as relay client. In other words, if two airwall clients (for example an agent and server) cannot contact each other directly (NAT, twice-NAT or port-blocking), and both airwall clients can connect to a third client, that third client will act as a relay point for the traffic between the two clients, it is like a smart SD-WAN Hub/Spoke and Mesh network combined! And I can share something with you, it really works.

The screenshot below shows a group I created to allow access to a virtual server with a relay VM that allows traffic between my mobile clients and that server.

In summary, I think that Airwall is one of the first true SASE clients out there, enabling end user devices (close to anyone) connectivity to any cloud, virtual server, or datacenter with some clicks inside the Conductor. I will be honest, the folks at Tempered have shared an evaluation license so that I can test out their software and solution for a few months. I have been testing it out over the past months and will share some use cases and setup experiences in a few upcoming posts.

Share this

3 Responses

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.