Reinventing application security with AppWANs

Image credit: Shutterstock
(Image credit: Shutterstock)
About the author

Mike Gorman is head of security and compliance at NetFoundry. Mike has been an engineer in new technology fields for over 20 years, tasked with building and rebuilding many technologies in the data transport and technology fields. 

Effective security today will not resemble security of the past decades.  It must support not only traditional endpoints, data centers and offices, it must be extended for a new world of cloud-delivered apps, mobile, and  IoT connected networks.  

The conundrum:  Much of the conversations around the failings of security have been about blaming users, such as when they click on harmful phishing links or when they use weak passwords. Or blaming network administrators when servers are not patched in time. However, playing the blame game does not solve the greater problem of truly secure connections. 

Today, Information is in motion between the edge and endpoint, over the Internet and WAN links, and between clouds.  Security was traditionally designed, built and accomplished by encrypting the connections between the internet and premises by using Access Control Lists (ACLs) on firewalls and routers, with the optimal place being nearest a traffic source. And for remote users and devices, VPNs, protected with encryption, passwords and cookies etc.

But in today’s world where users are in flight from place to place using many different devices for access, protecting applications this way is both impractical, and difficult to accomplish. Furthermore, it leaves too many openings for cyber thieves as there is only one line of defense to permeate.  The onus now is securing applications and content traveling through the cloud and IoT edge networks. Security must be built to reach a user device wherever it is (not to give access to an entire network in an office or data center, the way a VPN does. 

VPNs are not the answer for cloud delivered applications and IoT connected devices. VPNs can allow unfettered access to every network resource given to users on the physical network. And thus, bad actors who. Have VPN access can steal any resource from the network. 

Liberating security with software defined perimeter

Software-defined perimeter (SDP) offers hardened security beyond the limitations and vulnerabilities of VPNs, and is essential for cloud (multi-cloud).  SDP means implementing cloud-based access services to route traffic directly from the cloud to end users. It provides fine grained, customized connections that are specific to trusted users being connected to specific applications.  

Well-defined and approved access has to be given to specific applications. This touches on the notion of “Zero Trust” –t here is no wide pool of trusted users just based on a connection or pre-approved cookie implanted in their browser with a VPN service. 

AppWANs: building identity into applications

AppWANs work in the context of the cloud, zero trust to meet needs of individual users and devices, rather than groups, and doing so in a highly secure way that is customized for any application.  

AppWANs enable security pros and network administrators to punch a pinhole into any application or service, just for the user that is desired, and it becomes a highly sought after tool because the bona-fied user’s identity is attached to it. The AppWAN approach effectively places access control into the actual applications to bound to an identity that is not an address, and the location of the person no longer matters.  The result is a private zero-trust network, protecting applications from one edge to the other.   

Zero-trust networks are necessary to make each application’s security as agile as the applications, and not dependent on security services being provided by the underlying networks. 

The concept of Least privilege access comes into plays: An endpoint is only given access to specific applications, services, ports or protocols that they require, as defined by centralized access policies. The result is a multi-layered security approach means authenticating each user before they connect, providing zero network access until both endpoints authenticate.

Key principles:

  • Up the verification requirements for users/devices or deny all access  
  • Utilize certificates with hardware root of trust.  
  • Authenticate identity to the network infrastructure at every point, not just entry  

Image credit: Pixabay

Image credit: Pixabay

(Image credit: Image credit: Pixabay)

Going “dark” to protect data and assets

The greatest advantage of an AppWAN is that it applies security in very specific ways. For users and devices, a layer of identification and identity is created that is not tied to an address. Then the system enables a full policy engine, enabling it to enact fine-grained security rules, such as, restricting access from specific countries (e.g. Nigeria). The trusted user identity can be from a number of things, namely, an encrypted X509 certificate (their unique key).

The concept of a dark network denies any packets which have not been authorized, making the network a non-entity to hackers.   Even if a device inside the network is vulnerable, the deficiency is masked because the AppWAN will drop unauthorized externally originated attempts such as botnets before they can reach a vulnerable device or application.

All data is encrypted with strong, session by session, encryption, and transferred across the highly resilient and protected Secure Perimeter overlay network, providing protection against, man-in-the-middle, Denial of Service  Distributed Denial of Service attacks. 

The data plane of the traffic is determined between endpoints at time of creation of the session.  The encrypted data plane carried across multiple simultaneous paths. The transfer nodes do not have the keys. He keys are negotiated between the endpoints, no visibility into the data plane itself, thus hacking the transfer node (the virtual switch) that data out of it, the key to that data does not reside does not reside on that box. 

Image credit: Shutterstock

Image credit: Shutterstock

Cloud and application customization

One clear advantage of AppWANs are that they are software defined, and thus customizable for cloud-delivered applications.  As an app developer, using APIs mean not only can a user log into the Amazon counsel and build an environment. Developers can build a secure environment backed with the infrastructure, and not need to wait for ExpressRoute, or to have an MPLS service turned up. 

For example, a large bank could build an internal counsel that enables a secure cloud environment just for billing purposes. Then have the AppWAN that projects right along with it. Having such a sensitive data outpost in the cloud used to present challenges and risks that could not be overcome. But with a bubbled security installation using the AppWAN around it, the bank can rewrite routing table to send any outbound traffic from the bubbled perimeter and wrap around the cloud. 

The AppWAN results in a Virtual Private Cloud (VPC) for any organization. The only way data comes out of that cloud is fully enforceable, and not routed through a random location.  Now, network infrastructure and servers can be launched securely, form anywhere (e.g. 7 database servers in less than an hour) The networking portion happens in real time. Enterprises gain all of the benefits of cloud, while not suffering any of the traditional security drawbacks of the cloud, as they are enforcing their own stringent security policies for each service/app. 

Customization also allows for building security into an individual application. A new app needs to be protected, regardless of where it runs (e.g. Google store) and meet your policies for enrollment. IF the framework has a zero day bug that puts app at risk. If the security is built on your network (socket —the counterpoint is where the traffic termination point (Layer 4 address or port — now its a software construct) you maintain that pinhole and have no attack surface.  It doesn’t matter what is found on that code used, because nothing speaks to the logic.  Zero Trust thing. Build security on top of that stream.

Mike Gorman, Head of Security and Compliance at NetFoundry