One of the things presented by Tempered Networks at XFD3 was the extensive programmability capabilities of Airwall. Everything you do in Conductor can also be preformed leveraging a REST API. I think this is a really good feature that can really demonstrate the capabilities and principles of Intent-Based Networking . In this post, I’ll demonstrate what happens when you combine several technologies and trends together.
Background & use case description
Zero Trust is a paradigm/principle within Security that has gained quite some momentum. The core principle behind Zero Trust is that every single transaction should only be executed if it is properly authenticated and authorized. This can be an employee sending an email (workforce), a computer accessing the network (workspace), or two services exchanging data (workloads).
You could say that access to a resource is denied unless there is an explicit permit based on authentication (who are you) and authorization (are you allowed to).
Another trend in networking and security field is leveraging automation. In other words, instead of performing changes manually on-box, a script or program is defined that will perform the changes automatically for you on all devices, making sure that the change is performed consistently. There are of course requirements and disadvantages to automation, but that is for another post.
The success of the automation trend is only achievable by the programmability of the network devices; it is effectively a requirement for automation and any SDx solution. It means that you can perform changes in the infrastructure leveraging frameworks and API’s (often RESTful) using programming languages like Python and Swift.
As Airwall is fully programmable, I think it has a very powerfull intent-based Zero-Trust use case…
In network infrastructures, it is very common to have a centralized authentication and authorization server, which validates if you are allowed access to a specific switch, router or firewall. This is often implemented via the RADIUS protocol or TACACS+ protocol. This means that, in general, you as a network engineer, have network management credentials and are able to login to devices 24×7 to perform monitoring tasks and execute configuration changes.
However, in an ideal world, based on Zero-Trust, from a security perspective, you’d only want to allow access to the (often critical) network infrastructure when there is an actual incident or change request that involves that devices. Some say that this is just-in-time rights management, providing you only rights when needed. It is basically an implementation / interpretation of Zero-trust.
Unfortunately, a validation-check with an IT Service Management tool and CMDB is not a feature that is currently in Radius server implementations and would require some hacking or manual changes.
Proof of concept
But why not leverage Airwall and its programmability capabilities to achieve this. In other words, only allow access from a network management station to a managed device if there is a change or incident open in the IT Service Management tools.
You could also state the use case as: “I have an intent to perform changes to a specific managed device (can also be a server) only when there is a specific change request or incident open. “
This is definitely something which is possible with Airwall, as I will show below. I do not have access to a personal ITSM tool with full extensive API’s, a full Radius server setup and all other requirements, but I do have XCode (to build iOS / MacOS apps), access to conductor and a server that I manage via Airwall.
For the POC, I will use the following setup / construct:
- I have an overlay network (security policy) that allows my devices to connect to the server agent
- The overlay network is disabled by default
- Simple app instead of ITSM
I will create a very simple iPad/iPhone/Mac application that asks for the hostname, credentials and overlay network name. It will have two options, enable communication and disable communication, simulating what an ITSM can do.
- I will use ping and ssh to validate that communication is allowed or denied
- I will use the Mac Application as simulator of the ITSM tool, where I can enable/disable the access with a tip of a switch.
Summary
In conclusion, this POC shows that you can definitely implement Zero-Trust for the management of infrastructure, not only network but also server infrastructure.
I also think that this POC/demo is not only showing how powerful Airwall itself is, but it is a true demonstration of the possibilities are of Intent-Based Networking if you leverage these programmability capabilities and give them to software engineers. It has only taken me 1,5 hours to build this macOS app that can also run on an iPhone or iPad to validate the POC (granted, I can already code and demo’d some apps in Swift 😉 ).
One Response