Welcome to the Disposable Network

The majority of today’s corporate networks are built with legacy networking concepts we inherited from 30 years ago. Those old networks were fixed i.e. there were a known set of computers connected to each other with cables, hubs and switches. A network centric security model which takes such a fixed environment as “the inside” and protect against “outside” worked well because there weren’t many if any mobile or remote workers or BYOD devices that required outsider access to internal assets. And when remote access was needed, a VPN was basically the “best of breed” approach to solve the problem and help to easily bring those remote devices into the corporate network. With that VPN, those remote workers no longer had to copy files to between home and office or other locations.

The fundamental problem with that old model and the VPN is that “trust” is part of the core fabric of those old networks.

The cloud transformation and BYOD world we live in now, have invalidated that old security model, and necessitated the “kill the vpn” approach. The fundamental problem with that old model and the VPN is that “trust” is part of the core fabric of those old networks. That old paradigm operated on the principle of inherent trust for assets in a network. However, today, that interconnected trusted system is the main reason for a company like Travelex to be infected so broadly and easily by Sodinokibi ransomware.This approach is based on the assumption that every device, connection, assets, application, and share inside the perimeter of the network is safe and that there is no possibility of an internal compromise. 30 years ago, this “flawed” assumption did not create too many problems as the network was relatively static and the era of data breaches had not yet occurred. However, today, that interconnected trusted system is the main reason for a company like Travelex to be infected so broadly and easily by Sodinokibi ransomware. Trust and trusted assets mean that once a device is a part of the network, infected or not, It likely has full access to all the other resources such as computers, file shares, applications etc. This trust and connectivity enable those compromises and attacks to spread like wildfire throughout supposedly “secure” networks. The VPN’s we rely on basically become “pipes” that funnel trusted connections for infected assets deeper into the core network. The whole system and approach are a house of cards.

It is apparent that extending legacy networks to remote users through VPNs, especially to 3rd parties such as partners, affiliates, contractors significantly increases the risk of breach, and that the modern enterprise must think differently to adapt to the new digital space we live in.

An ideal solution should

  1. Allow only secure private access without exposing the resources to the Internet or over-expose unnecessary resources
  2. Be cloud-native and have a zero-trust architecture to operate in environments of cloud and post-cloud era
  3. Offer full visibility into users’ activities, enabling security teams to manage 3rd party risks and auditing requirements for compliance
  4. Be friction-free to implement and use

The new network: “Application Networks”

What if, instead of trying to connect devices to each other, we simply connect the apps on those devices each other? After all, every workflow involves a form of app to app communication and as long as this is achieved, we would not need to fall back to legacy methods of building networks. In doing this we could essentially eliminate the entire issue that faces trying to re-engineer those already failed network systems.

At TransientX, we have created a new way of networking by approaching networking requirements with an app-centric approach. After all, applications are the tools that people use to access data. Applications are the “storage media” that keep keys to back-end systems, or store enterprise data. Applications can reside anywhere, on users’ mobile phones, on partners laptops, in a container on a private data center or in a server in a public cloud. In truth, they are the “real endpoints” that need to network with each other.

Applications are the tools that people use to access data; they are the “storage media” that keep keys to back-end systems, or store enterprise data. In truth, they are the “real endpoints” that need to network with each other.

In this new paradigm, we treat applications as if they are devices, and build virtual networks of applications, instead of on the devices on which they reside. This way, when an Outlook application needs to connect to a private Exchange server, or an SSH client needs to connect to a private Linux server, a temporary virtual network over the internet is created, with Outlook and Exchange or SSH client and Linux Server being the only elements in the network. When they are done, the network is disposed. That connection and all its affiliated potential risks and threats are dynamically obliterated using our solution. The risk is effectively negated, period.

Applications can reside anywhere; on mobile devices, desktop PCs, Linux servers or under any network topology, behind firewalls, proxies, NATs etc. They can also use any protocol from IMAP to HTTPS, to communicate. Keeping all these complexities in mind, technically speaking, building an application network is not so straightforward. To be able to work with applications on any device, we introduced a new type of container called “micro-containers”. Our micro-containers are similar to docker containers but as the name implies, they are lighter. But unlike docker containers, they do not require application preparation, they support unmodified applications and work on unmodified devices, without requiring any admin or root privileges.

Our micro-containers are also capable of communicating with each other, independent of the details and complexities of the underlying physical network topology. This is due to the fact that they are armed with our custom TCP/IP stack that provides connectivity on any topology.

As a result of these innovations, today, we are the only company which can offer the use of “disposable networks” to address some of the most challenging problems that IT teams are facing, from zero trust transformation to 3rd party vendor risk management.

Disposable Networks and 3rd Party Access

Our application networks are built and destroyed with a very low computational cost, on demand, and hence are disposable. They are technically classified as overlay networks i.e. networks over networks and in our case, they are encrypted hidden overlay networks of apps built transparently over the internet. This new solution allows us to create a new network for every user in that each user has his/her own network of authorized apps, his/her own view of the same underlying physical network, isolated from other users.

While allowing 3rd party users to access private resources, IT teams can easily create a virtual network of apps and simply allow them to use their own private app network. In doing so, they would be solving the following challenges:

  1. 3rd party users are not brought into private networks

    Unlike when using VPNs, 3rd party users are not joining the private corporate networks for access. Instead, they are using a temporary app network built outside over the Internet. This way risk of breach and lateral movement is contained significantly.
  2. Resources are not exposed to the Internet

    Resources are not exposed to the Internet Application networks are private, and the applications being accessed are invisible. They cannot be accessed from the internet despite they could be accessed remotely by authorized users. Their pre-authenticated and ephemeral nature also effectively prevents DOS/DDOS attacks.
  3. Zero trust is in its fabric

    Application networks are built after authentication and authorization only. The set of resources or apps available in the network is user specific and can be dynamically adjusted by IT teams.

We are very excited to offer disposable network technology in our TransientAccess product.

You can learn more about it at: TransientAccess