We’ve heard it all before, right?

Headliners of network breaches of compromised financial and personally identifiable information. Cloud security challenges like securing unmanaged traffic, user bypass, IoT devices, and how to ensure data workflow resiliency? Then there are decisions like going with an API or proxy-based approach to security? Do we use Appliances or software? Where to find security unicorns to run it all? I can go on, but what I mentioned are just a fraction of the daily challenges you face in your roles as digital leaders, IT leaders, CSOs, and CISOs. These challenges and complexities are the stuff of nightmares that keeps you up at night…

Unless Tempered Networks’ Secure IDN has been deployed. Gone are the days when engineers create a network to get things conveniently connected first and then figure out how to secure said network. What it truly boils down to is this; Secure Identity Defined Networking from Tempered Networks helps you build inherently secure networks from the get-go. And, to relieve some of the complexities in your daily roles, IDN was designed to be done in a real simple manner; 3-clicks and you’re up and running.

Wait, what? Three mouse clicks and I not only have a network up and running, but a secure network based on identity of the devices I add to it? “What sorcery is this”, you ask? Let’s go over some data elements to better understand what Identity Defined Networking is and how it is secured.

Tempered Network’s IDN works as an overlay fabric to your current infrastructure (underlay) and is secured by the Host Identity Protocol (HIP), Encapsulating Security Payload (ESP), Zero Trust, Cloaking and Stateful Packet Inspection (SPI) Firewalls.

IDN provides a trusted Host Identity Namespace that serves as a unified networking and security policy enforcement across a single network architecture. The fabric still uses your host’s IP address for its network location but replaces the hosts IP address used as the host identity, with a HIP provided cryptographic ID to uniquely verify the machine’s identity. The IDN Fabric, or the Overlay’s perimeter, is defined by the hosts you add to the network overlay policy. This means

that your secure overlay perimeter doesn’t have to encompass a whole network edge, the perimeter can be as restrictive as a single host.

One of the great things about IDN is there’s no need to change IP schema when the IDN components are installed in your network, but you can still use your own IP schema with global IP mobility and resiliency, free of IP and DNS limitations. Here are some additional definitions that will help better explain IDN and how it can help you defeat those night terrors.

Host Identity Protocol: An IETF ratified standard that replaces the IP address typically used for host identity with a cryptographic identity. HIP provides authentication and authorization based on the cryptographic identity prior to any transport and data exchange is accomplished through an encapsulating security payload.

The IDN Fabric consists of three levels of components; Orchestration, Enforcement, and Routing. Each of which can comprise of software, appliance, or both.

Orchestration: The Conductor allows the administrator to create, manage, automate policies, and trigger policy events to all Enforcement elements in the overlay.

Enforcement: The HIPservices that run on, adjacent, or inline to any host and acts as the overlay network policy and security enforcement point. Encapsulating Security Payloads are enforced by the HIPservices according to the policies the Conductor provides.

Routing: The HIPrelay is an Identity Based Router, a world’s first, that provides machine-to-machine connectivity between private or non-routable endpoints. The HIPrelay can also be used for ESP-resiliency - if your local secure HIPserver to HIPserver communication fails, the HIPrelay can be used as an ESP failover mechanism to keep communications alive.

Let’s bring the conversation back to what’s securing access to the IDN, like “cloaking”. Simply put, IDN cloaking is accomplished by adding your networked devices into the IDN fabric (also known as our Overlay). Once in our Overlay or behind one of our HIPservices, that device is no longer discoverable in your existing network (also known as the Underlay).

Zero Trust means that whatever you place in our Overlays, that network device will not be accessible by other devices outside of an Overlay Whitelist Policy, nor is it able to access anything beyond its Enforcer element (HIPservice) without a specific whitelist policy to do so.

Once a Network Overlay is created and end devices are added, more security can be achieved by deploying the Enforcer’s (HIPservice) SPI Firewall, restricting traffic to specific hosts and services.

Putting it all together, this is what a typical three click IDN deployment would look like:

The Underlay, your existing network.

 

 

The IDN Fabric is created with the Enforcement components – the HIPservices (HIPswitch Appliance, Virtual HIPswitch, HIPapp, or HIPswitch Cloud).

 

Devices removed from Underlay and added to Overlay. There is Zero Trust until an Overlay Network Policy is created for these devices.

Step 1: Create an Overlay Network Policy - each color (orange, green, purple) in the following diagram represents a separate Overlay Network Policy.

Step2: Add devices to the Overlay Network Policy – devices are added to each color coordinated Overlay Network Policy (orange, green, purple).

Step 3: Create Whitelist Policies between specific devices to allow communication and data sharing - the lines connecting the color coordinated devices represent ESP tunnels, which are allowed because of their Whitelist Policies.

In this scenario, there is Zero Trust between disparate colored Overlay Network Policies. Only orange devices can communicate with other orange devices, green to green and purple to purple. Unless a specific policy is created, the orange devices cannot communicate with the green, purple, or Underlay devices. This is also true for the green, purple, and underlay devices to each other. The underlay devices located in your existing network are still capable of freely communicating within the Underlay.

The Overlay (colored) devices are cloaked from the Underlay network and each Overlay device is cloaked from any devices enforced with a disparate colored policy.

 

The three steps to creating these secure networks are typically done manually, but with the Conductor’s API, these three steps and many other events can be accomplished with simple API calls.

There you have it, a 5-minute explanation of Tempered Networks’ Secure Identity Defined Networking. IDN capabilities may not eliminate all your nightmares, but it can eliminate some nightmares by safeguarding sensitive data, meeting compliance, and automatically revoking compromised devices. Your world is complex and with it comes complex decisions. IDN can help ease that complexity and help to increase productivity by giving you easy to manage micro-segmentation, unconstrained data and resource mobility through secure access control from anywhere with sub-second failover for data and workload resiliency. All manageable through the Conductor with great ease, no unicorns necessary.

For more IDN details and use cases, please visit Tempered Networks.

 

 

References

Heltzel, Paul (2018, January 8). The 12 biggest issues IT faces today [Blog post].

Retrieved from https://www.cio.com/article/3245772/it-strategy/the-12-biggest-issues-it-faces-today.html

 

Wall Street Journal (2018, May 29). What Keeps CIOs Up at Night? [Journal Report].

Retrieved from https://www.wsj.com/articles/what-keeps-cios-up-at-night-1527646381

 

Douglas, Joshua (2017, September 13). 5 Problems That Keep CISOs Awake at Night [Blog post].

Retrieved from https://www.darkreading.com/endpoint/5-problems-that-keep-cisos-awake-at-night/a/d-id/1329854

 

0 Comments
Thursday, June 28, 2018 By Anonymous (not verified)