defined perimeter

Safe-T SDP- Why Rip and Replace your VPN?

Although organizations realize the need to upgrade their approach to user access control. The deployment of existing technologies is holding back the introduction of Software Defined Perimeter (SDP). A recent report carried out by the Cloud Security Alliance (CSA) on the “State of Software Defined Perimeter” states that the main barrier to adopting SDP is the existing in-place security technologies.

One can understand the reluctance to take the leap. After all, VPNs have been a cornerstone of secure networking for over two decades. They do provide what they say; secure remote access. However, they have not evolved to appropriately secure our developing environment. In fact, the digital environment has changed considerably in recent times. There is a big push for the cloud, BYOD, and remote workers, thereby putting pressure on existing VPN architectures. As our environment evolves, the existing security tools and architectures must evolve also.

Undoubtedly, there is a common understanding of the benefits of adopting the zero-trust principles that SDP provides over traditional VPNs. But the truth that organizations want even safer, less disruptive, and less costly deployment models cannot be ignored. VPNs aren’t a solution that works for every situation. It is not enough to offer solutions that would involve ripping the existing architectures completely or even putting SDP on certain use cases. The barrier to adopting SDP involves finding a middle ground.

 

Safe-T; Providing the middle ground

Safe-T is aware of this need for a middle ground. Therefore, in addition to the standard SDP offering, Safe-T also offers this middle-ground, to help the customer on the “journey from VPN to SDP”, resulting in a safe path to SDP.

Now organizations do not need to rip and replace the VPN. SDP and VPNs can work together, thereby yielding a more robust security infrastructure. Having network security that can bounce you between IP address locations can make it very difficult for hackers to break in. Besides, if you already have a VPN solution that you are comfortable with, you can continue using it and pair it with Safe-T’s innovative SDP approach. By adopting this new technology you get equipped with a middle-ground that not only improves your security posture but also maintains the advantages of existing VPN.

Recently, Safe-T has released a new version of its SDP solution called ZoneZero that enhances VPN security by adding SDP capabilities. Adding SDP capabilities allows the exposure and access to applications, and services. The access is granted only after assessing the trust, based on policies for an authorized user, location, and application. In addition, access is granted to the specific application or service, rather than the network, as you would provide with a VPN.

Deploying SDP on top of the existing VPN offers a customized and scalable zero trust solution. It provides all the benefits of SDP while lowering the risks involved in adopting the new technology. Currently, Safe-T’s ZoneZero is the only SDP solution in the market with a primary focus on enhancing VPN security by adding zero trust capabilities, rather than replacing it.

 

The challenges of just using a traditional VPN

While VPNs have stood the test of time, today, we know that the true security architecture is based upon the concept of zero trust access. VPNs operating by themselves are unable to offer optimum security. Now, let’s examine some of the common shortfalls.

The VPN lacks in the sense that they are not equipped to grant access on a granular, case-by-case level. This is a major problem that SDP addresses. According to the traditional security setup, in order to get access to an application, you had to connect a user to a network. Whereas, the users that were not on the network, for example, remote workers, we needed to create a virtual network to place the user on the same network as the application.

To enable external access, organizations started to implement remote access solutions (RAS) to restrict user access and create secure connectivity. To provide application access, an inbound port is exposed to the public internet. However, this open port is visible to anyone on the internet and not just to the remote workers.

From a security standpoint, the idea of network connectivity to access an application is likely to bring many challenges. We then moved to the initial layer of zero trust, which was to isolate different layers of security within the network. This provided a way to quarantine the applications that are not meant to be seen, as dark. But this leads to a sprawl of network and security devices.

For example, you could use inspection path control with a stack of hardware. This enabled the users to only access what they were allowed to, based on the blacklist security approach. Security policies provided a broad-level and overly permissive access. The attack surface was simply too wide. Also, the VPN just displays static configurations that have no meaning. For example, a configuration may state that this particular source can reach this destination by using this port number and policy.

However, with this configuration, the contextual configuration is not taken into consideration. There are just ports and IP addresses and the configuration offers no visibility into the network to see who, what, when, and how they are connecting with the device.

More than often, access policy models are coarse-grained, which provides users with more access than is required. This model does not follow the least privilege model. The VPN device provides only the network information and the static policy does not dynamically change based on the levels of trust.

Say, for example, the user’s anti-virus software is accidentally turned off or by malicious malware. Or maybe you want to re-authenticate when certain user actions are performed. In such cases, a static policy cannot dynamically detect this and change configuration on the fly. They should actually be able to express and enforce the policy configuration based on the identity, which takes into consideration both the user and the device.

 

The SDP acceptance

The new technology adoption rate can be slow initially. The primary reason could be the lack of understanding that what you have in place today, by itself, is not the best for your organization in the future. Maybe now is the time to stand back and ask if this is the future that we really want.

All the money and time you have spent on the existing technologies are not evolving at pace with today’s digital environment. This indicates the necessity for new capabilities to be added. These get translated into different meanings based on the CIO and CTO roles of an organization. The CTOs are passionate to embrace the new technologies and invest in the future. They are always on the lookout to take advantage of new and exciting opportunities in technology.

However, the CIO looks at things in a different manner. Usually, the CIO wants to stay with the known and is reluctant to change even in case of loss of service. Their sole aim is to keep the lights on.

This shines the torch on the need to find the middle ground. And that middle-ground is to adopt a new technology that has endless benefits for your organization. The technology should be able to satisfy the CTO group while also taking every single precaution and not disrupting the day-to-day operations.

The push by the marketers

There is a clash between what is needed and what the market is pushing. The SDP industry standard is to encourage the customers to rip and replace their VPN in order to deploy their SDP solution. But the customers have invested in a comprehensive VPN and are reluctant to replace it.

The SDP market initially pushed for a rip and replace model, which would eliminate the use of traditional security tools and technologies. This should not be the recommended case since the SDP functionality can overlap with the VPNs. Although the existing VPN solutions have their drawbacks there should be an option to use the SDP in parallel. Thereby, offering the best of both worlds.

 

How does Safe-T address this?

Safe-T understands that there is a need to go down the SDP path, but you may be reluctant to do a full or partial VPN replacement. So let’s take your existing VPN architecture and add the SDP capability to it.

The solution is placed after your VPN. The existing VPN communicates with Safe-T ZoneZero which will do the SDP functions after your VPN device. From an end user’s perspective, they will continue to use their existing VPN client. In both cases, the users operate as normal. There are no behavior changes and the users can continue using their VPN client.

For example, they authenticate with the existing VPN as before. But the VPN communicates with SDP for the actual authentication process as opposed to communicating with, for example, the Active Directory (AD).

What do you get from this? From an end-user’s perspective, their day-to-day process does not change. Also, instead of placing the users on your network as you would with a VPN, they are switched over to the application-based access. Even though they are using a traditional VPN to connect, they are still getting the full benefits of SDP.

This is a perfect stepping stone on the path toward SDP. Significantly, it provides a solid bridge to an SDP deployment. It will lower the risk and cost of the new technology adoption with minimal infrastructure changes. It removes the pain caused by deployment.

 

The ZoneZero™ deployment models

Safe-T offers two deployment models; ZoneZero Single-Node and Dual-Node.

With the single-node deployment, a ZoneZero virtual machine is located between the external firewall/VPN and the internal firewall. All VPN is routed to the ZoneZero virtual machine and it controls which traffic continues to flow into the organization.

In the dual-node deployment model, the ZoneZero virtual machine is located between the external firewall/VPN and the internal firewall. And an access controller is in one of the LAN segments, behind the internal firewall.

In both cases, the user opens the IPSEC or SSL VPN client and enters the credentials. The credentials are then retrieved by the existing VPN device and passed over RADIUS or API to ZoneZero for authentication.

SDP is charting the course to a new kind of network and security architecture. But at this time, a middle ground can reduce the risks associated with the deployment. The only viable option is to run the existing VPN architectures in parallel with SDP. This way, you get all the benefits of SDP with minimal disruption.

 

Zero Trust Access

Safe-T; A Progressive Approach to Zero Trust Access

The foundations that support our systems are built with connectivity and not security as an essential feature. TCP connects before it authenticates. Security policy and user access based on IP lack context and allow architectures that exhibit overly permissive access. Most likely, this will result in a brittle security posture enabling the need for Zero Trust Access.

Our environment has changed considerably, leaving traditional network and security architectures vulnerable to attack. The threat landscape is unpredictable. We are getting hit by external threats from all over the world. However, the environment is not just limited to external threats. There are insider threats also within a user group, and insider threats, across user group boundaries.

Therefore, we need to find ways to decouple security from the physical network and also decouple application access from the network. To do this, we need to change our mindset and invert the security model. Software-Defined Perimeter (SDP) is an extension of zero trust which presents a revolutionary development. It provides an updated approach that current security architectures fail to address. SDP is often referred to as Zero Trust Access (ZTA).

Safe-T’s package of the access control software is called: Safe-T Zero+. Safe-T offers a phased deployment model, enabling you to progressively migrate to zero-trust network architecture while lowering the risk of technology adoption. Safe-T’s Zero+ model is flexible to meet today’s diverse hybrid I.T requirements. It satisfies the zero-trust principles that are used to combat today’s network security challenges.

 

Network Challenges

  • Connect First and Then Authenticate

TCP has a weak security foundation. When clients want to communicate and have access to an application: they first set up a connection. It is only after the connect stage has been carried out, can the authentication stage be accomplished. Unfortunately, with this model, we have no idea who the client is until they have completed the connect phase. There is a possibility that the requesting client is not trustworthy.

 

  • The Network Perimeter

We began with static domains, whereby internal and external segments are separated by a fixed perimeter. Public IP addresses are assigned to the external host and private addresses to the internal. If a host is assigned a private IP, it is thought to be more trustworthy than if it has a public IP address. Therefore, trusted hosts operate internally, while untrusted operate externally to the perimeter. Here, the significant factor that needs to be considered is that IP addresses lack user knowledge to assign and validate trust.

Today, I.T has become more diverse since it now supports hybrid architectures with a variety of different user types, humans, applications, and the proliferation of connected devices. Cloud adoption has become the norm these days since there is an abundance of remote workers accessing the corporate network from a variety of devices and places.

The perimeter approach no longer reflects the typical topology of users and servers accurately. It was actually built for a different era where everything was inside the walls of the organization. However, today, organizations are increasingly deploying applications in the public clouds that are located in geographical locations. These are the locations that are remote from an organization’s trusted firewalls and the perimeter network. This certainly stretches the network perimeter.

We have a fluid network perimeter where data and users are located everywhere. Hence, now we operate in a completely new environment. But the security policy controlling user access is built for static corporate-owned devices, within the supposed trusted LAN

 

  • Lateral Movements

A major concern with the perimeter approach is that it assumes a trusted internal network. However, evidently, 80% of threats are from internal malware or a malicious employee that will often go undetected.

Besides, with the rise of phishing emails, an unintentional click will give a bad actor broad-level access. And once on the LAN, the bad actors can move laterally from one segment to another. They are likely to navigate undetected between, or within the segments.

Eventually, the bad actor can steal the credentials and use them to capture and exfiltrate valuable assets. Even social media accounts can be targeted for data exfiltration since they are not often inspected by the firewall as a file transfer mechanism.

 

  • Issues with the Virtual Private Network (VPN)

What is happening with traditional VPN access is that the tunnel creates an extension between the client’s device and the application’s location. The VPN rules are static and do not dynamically change with the changing levels of trust on a given device. They provide only network information which is a crucial limitation.

Therefore, from a security standpoint, the traditional method of VPN access enables the clients to have broad network-level access. This makes the network susceptible to undetected lateral movements. Also, the remote users are authenticated and authorized but once permitted to the LAN they have coarse-grained access. This obviously creates a high level of risk as undetected malware on a user’s device can spread to an inner network.

Another significant challenge is that VPNs generate administrative complexity and cannot easily handle cloud, or multiple network environments. They require the installation of end-user VPN software clients and knowing where the application that they are accessing is located. Users would have to make changes to their VPN client software to gain access to the applications situated at different locations. In a nutshell, traditional VPNs are complex for administrators to manage and for users to operate.

With public concern over surveillance, privacy, and identity theft growing, an increasing number of people are turning to VPNs to help keep them safer online. But where should you start when choosing the best VPN for your needs?

Also, poor user experience is most likely to occur as you need to backhaul the user traffic to a regional data center. This adds latency and bandwidth costs.

In recent years, torrenting has started to become increasingly popular amongst computer users who wish to download files such as movies, books, and songs. Without having a VPN, this could risk your privacy and security. It is also important to note that you should be very careful when it comes to downloading files to your computer as they could cause more harm than good. 

 

Can Zero Trust Access be the Solution?

The main principle that ZTA follows is that nothing should be trusted. This is regardless of whether the connection is originating inside or outside the network perimeter. Reasonably, today we have no reason to trust any user, device, or application, some companies may try and decrease the accessibility with the use of programs like office 365 distribution group to allow and disallow users and devices’ specific network permissions. You know that you cannot protect what you cannot see but the fact that you also cannot attack what you cannot see also holds true. ZTA makes the application and the infrastructure completely undetectable to unauthorized clients, thereby creating an invisible network.

Preferably, application access should be based on contextual parameters, such as who/where the user is located, the judgment of the security stance of the device, and then a continuous assessment of the session should be performed. This moves us from network-centric to user-centric, providing a connection-based approach to security. Security enforcement should be based on user context and include policies that matter to the business. It should be unlike a policy based on subnets that have no meaning. The authentication workflows should include context-aware data, such as device ID, geographic location, and the time and day when the user requests access.

It’s not good enough to provide network access. We must provide granular application access with a dynamic segment of 1. Here, an application microsegment gets created for every request that comes in. Micro-segmentation creates the ability to control access by subdividing the larger network into small secure application micro perimeter internal to the network. This abstraction layer puts a lockdown on lateral movements. In addition, zero trust access also implements a policy of least privilege by enforcing controls that enable the users to have access only to the resources they need to perform their tasks.

 

Characteristics of Safe-T

Safe-T has 3 main pillars to provide a secure application and file access solution with:

1) An architecture that implements zero trust access,

2) A proprietary secure channel that enables users to remotely access/share sensitive files and

3) User behavior analytics.

Safe-T’s SDP architecture is designed to substantially implement the essential capabilities delineated by the Cloud Security Alliance (CSA) architecture. Safe-T’s Zero+ is built using these main components:

The Safe-T Access Controller is the centralized control and policy enforcement engine that enforces end-user authentication and access. It acts as the control layer, governing the flow between end-users and backend services.

Secondly, the Access Gateway acts as a front-end to all the backend services published to an untrusted network. The Authentication Gateway presents to the end-user in a clientless web browser. Hence, a pre-configured authentication workflow is provided by the Access Controller. The authentication workflow is a customizable set of authentication steps, such as 3rd party IDPs (Okta, Microsoft, DUO Security, etc.). In addition, it has built-in options, such as captcha, username/password, No-Post, and OTP.

 

Safe-T Zero+ Capabilities

The Safe-T Zero+ capabilities are in line with zero trust principles. With Safe-T Zero+, clients requesting access must go through authentication and authorization stages before they can access the resource. Any network resource that has not passed these steps is blackened. Here, URL rewriting is used to hide the backend services.

This reduces the attack surface to an absolute minimum and follows the Safe-T’s axiom: If you can’t be seen, you can’t be hacked. In a normal operating environment, for the users to get access to services behind a firewall, they have to open ports on the firewall. This presents security risks as a bad actor could directly access that service via the open port and exploit any vulnerabilities of the service.

Another paramount capability of Safe-T Zero+ is that it implements a patented technology called reverse access to eliminate the need to open incoming ports in the internal firewall. This also eliminates the need to store sensitive data in the demilitarized zone (DMZ). It has the ability to extend to on-premise, public, and hybrid cloud, supporting the most diverse hybrid and meeting the I.T requirements. Zero+ can be deployed on-premises, as part of Safe-T’s SDP services, or on AWS, Azure, and other cloud infrastructures, thereby protecting both cloud and on-premise resources.

Zero+ provides the capability of user behavior analytics that monitors the actions of protected web applications. This allows the administrator to inspect the details of anomalous behavior. Thence, forensic assessment is easier by offering a single source for logging.

Finally, Zero+ provides a unique, native HTTPS-based file access solution for the NTFS file system, replacing the vulnerable SMB protocol. Besides, users can create a standard mapped network drive in their Windows explorer. This provides a secure, encrypted, and access-controlled channel to shared backend resources.

 

Deployment Strategy

Safe-T customers can exclusively select an architecture that meets their on-premise or cloud-based requirements.

 

There are 3 options:

i) The customer deploys three VMs: 1) Access Controller, 2) Access Gateway, and 3) Authentication Gateway. The VMs can be deployed on-premises in an organization’s LAN, on Amazon Web Services (AWS) public cloud, or on Microsoft’s Azure public cloud.

ii) The customer deploys the 1) Access Controller VM and 2) Access Gateway VM on-premises in their LAN. The customer deploys the Authentication Gateway VM on a public cloud, such as AWS or Azure.

iii) The customer deploys the Access Controller VM on-premise in the LAN and Safe-T deploys and maintains two VMs 1) Access Gateway and 2) Authentication Gateway; both hosted on Safe-T’s global SDP cloud service.

 

ZTA Migration Path

Today, organizations recognize the need to move to zero trust architecture. However, there is a difference between recognition and deployment. Also, new technology brings with it considerable risks. Chiefly, traditional Network Access Control (NAC) and VPN solutions fall short in many ways, but a rip and replace model is a very aggressive approach.

To begin the transition from legacy to ZTA, you should look for a migration path that you feel comfortable with. Maybe you want to run a traditional VPN in parallel or in conjunction with your SDP solution and only for a group of users for a set period of time. A probable example could be: choosing a server used primarily by experienced users, such as DevOps or QA personnel. This ensures that the risk is minimal if any problem occurs during the phased deployment of SDP access in your organization.

A recent survey carried out by the CSA indicates that SDP awareness and adoption is still in an early stage. However, when you do go down the path of ZTA, vendor selection which provides an architecture that matches your requirements is the key to successful adoption. For example, look for SDP vendors who allow you to continue using your existing VPN deployment while adding

SDP/ZTA capabilities on top of your VPN. This could sidestep the possible risks involved if you switch to completely new technology.

 

VPN virtual private network conncetion concept. Lan cable and a router with different flags. 3d illustration

Remote Browser Isolation; Complementing the SDP Story

Our digital environment has been transformed significantly. Unlike earlier times, we now have a bunch of different devices, access methods, and types of users accessing applications from a variety of locations. This makes it more difficult to know which communications can be trusted. The perimeter-based approach to security can no longer be limited to just the physical location of the enterprise. In this modern world, the perimeter is becoming increasingly difficult to enforce as organizations adopt mobile and cloud technologies. Hence, the need for Remote Browser Isolation (RBI). Under these circumstances, the perimeter is more likely to be breached; it’s just a matter of time. A bad actor would then be relatively free to move laterally, potentially accessing the privileged intranet and corporate data, both on-premises and in the cloud. Therefore, we must operate under the assumption that users and resources on internal networks are as untrustworthy as those on the public internet, and design enterprise application security with this in mind. 

 

What within the perimeter leads us to assume that it can no longer be trusted?

Security becomes less and less tenable once there are many categories of users, device types, and locations. The very fact that users are diverse means that it is not possible, for example, to slot all vendors into one user segment with uniform permissions. As a result, access to applications should be based on contextual parameters such as who and where the user is. And sessions should be continuously assessed to ensure they’re legit.  We need to find ways to decouple security from the physical network and more importantly, to decouple application access from the network. In short, we need a new approach to providing access to applications that is cloud, network, and device agnostic. This is where Software-Defined Perimeter (SDP) comes into the picture.

 

What is a Software-Defined Perimeter (SDP)?

SDP complements zero trust, which considers both internal and external networks and actors to be completely untrusted. The network topology is divorced from trust. There simply is no concept of inside or outside of the network. This may result in users not automatically being granted broad access to resources, simply by virtue of their being inside the perimeter. 

Primarily, security pros must focus on solutions where they can set and enforce discrete access policies and protections for those requesting to use an application. SDP lays the foundation and secures the access architecture, which enables an authenticated and trusted connection between the entity and the application.

Unlike security based solely on IP, SDP does not grant access to network resources based on a user’s location. Access policies are rather based on device, location, state, and associated user information, along with other contextual elements. The applications are considered in the abstract, so whether they run on-premise or in the cloud is irrelevant to the security policy.

 

Periodic Security Checking

Clients and their interactions are periodically checked to make sure they are complying with the security policy. Periodic security checking protects against any additional actions or requests that are not allowed while the connection is open. Let’s say, you have a connection open to a financial application and users are accessing the recording software to record the session. In this case, the SDP management platform can check if the software has been started or not. If so, it employs protective mechanisms to ensure smooth and secure operation.

 

Microsegmentation

Front-end authentication and periodic checking are one part of the picture. However, we not only need to go a layer deeper to secure the front door to the application but also must secure the numerous doors within, which can potentially create additional access paths. Primarily, this is the job of microsegmentation. It’s not sufficient just to provide network access. We must enable granular application access for dynamic segments of 1. In this scenario, a microsegment is created for every request that comes in. Microsegmentation creates the minimal accessible network required to get specific tasks done smoothly and securely. This is accomplished by subdividing larger networks into small secure and flexible micro-perimeters.

 

Introducing Remote Browser Isolation (RBI)

SDP provides mechanisms to prevent the possibility of lateral movement once users are inside the network. However, we also need to address how external resources located on the internet and public clouds can be accessed while protecting end-users, their devices, and the networks to which they connect. This is where remote browser isolation (RBI) comes into the picture.

Initially, we started with browser isolation, which protects the user from external sessions by isolating the interaction. Essentially, it generates complete browsers within a virtual machine on the endpoint, providing a proactive approach to isolate user’s sessions from, for example, malicious websites, emails, and links. But these solutions do not reliably isolate the web content from the end-user’s device, which is of course, on the network.

Remote browser isolation takes local browser isolation to the next level by enabling the rendering process to take place remote from the user’s device, in the cloud. Because only a clean data stream touches the endpoint, users can securely access untrusted websites from within the perimeter of the protected area.

 

SDP along with Remote Browser Isolation (RBI)

In many important ways, remote browser isolation complements the SDP approach. When you access a corporate asset, you operate within the SDP. But when you need to access external assets, RBI is needed to keep you safe.

Zero trust and SDP are about authentication, authorization, and accounting (AAA) for internal resources, but there must be secure ways to get to external resources as well. For this, RBI secures browsing elsewhere on your behalf. No SDP solution can be complete without including rules to secure external connectivity. RBI takes the essence of zero trust to the next level by securing the internet browsing perspective. If access is to an internal corporate asset we create a dynamic tunnel of one individualized connection. For external access, RBI allows information to be transferred without full, risky connectivity.

This is particularly crucial when it comes to email attacks, like phishing. Malicious actors use social engineering tactics to convince recipients to trust them enough to click on embedded links. Quality RBI solutions protect users by “knowing” when to allow user access while preventing malware from entering endpoints; entirely blocking malicious sites; or protecting users from entering confidential credentials by enabling read-only access.

 

The RBI Components

To understand just how RBI works, let’s look under the hood of Ericom Shield. With RBI, for every tab that a user opens on his or her device, the solution spins up a virtual browser in its own dedicated Linux container in a remote cloud location. For example, if the user is actively browsing 19 open tabs on his Chrome browser, each will have a corresponding browser in its own remote container. This sounds like it takes a lot of computing power but enterprise-class  RBI solutions do a lot of optimizations to ensure that it is not eating up too much of the endpoint resources.

If a tab is unused for a period of time, the associated container is automatically terminated and destroyed. This frees up computing resources and also eliminates the possibility of persistence. As a result, whatever malware may have resided on the external site being browsed is destroyed, and cannot accidentally infect the endpoint, server, or cloud location. When the user shifts back to the tab, he is reconnected in a fraction of a second to the same location but with a fresh container, creating a secure enclave for internet browsing. 

Website rendering is carried out in real-time from the remote browser. The web page is translated into a media stream, which then gets streamed back to the end-user via HTML5 protocol. In reality, the browsing experience is made out of images. When you look at the source code on the endpoint browser, you will find that the HTML code consists solely of a block of Ericom-generated code. This block manages to send and receiving of images via the media stream.

Regardless of whether the user is accessing the Wall Street Journal or YouTube, they are always going to get the same source code from Ericom Shield. This is ample proof that no local download, drive-by download, or any other contact that may try to hook up into your endpoint is ever going to get there, as it does not come into contact with the endpoint. It runs only remotely, in a container located outside of the local LAN. The browser farm does all the heavy — and dangerous — lifting via container-bound browsers that read and execute the uniform resource locator (URL) requests coming from the user. 

 

Summary

SDP vendors have figured out device user authentication and how to continuously secure sessions. However, vendors are now looking for a way to secure the tunnel through to external resource access.  If you use your desktop to access a cloud application, the session can be hacked or compromised. But with RBI, you can maintain one-to-one secure tunneling. With a dedicated container for each specific app, you are ensured of an end-to-end zero-trust environment. 

RBI based on hardened containers, and with a rigorous process to eliminate malware through limited persistence, forms a critical component of the SDP story. The power of RBI is that it stops both known and unknown threats, making it a natural evolution from the zero trust perspective.

 

 

 

 

 

 

 

Cyber security threat. Computer screen with programming code. Internet and network security. Stealing private information. Using technology to steal password and private data. Cyber attack crime

Software-defined perimeter (SDP): A disruptive technology

There has been tremendous growth in the adoption of the software-defined perimeter (SDP) over the last few years. This has resulted in SDP becoming a disruptive technology, especially when it comes to replacing, or working together with the existing virtual private network. Why? Because the steps that software-defined perimeter proposes are needed. Today’s network security architectures, tools, and platforms are lacking in many ways when trying to combat the current security threats.

From a bird’s eye view, the stages of zero trust software-defined perimeter are relatively simple. SDP requires that endpoints both internal and external to an organization must authenticate and then be authorized before being granted network access. Once these steps are carried out, two-way encrypted connections are created between the requesting entity and the intended protected resource.

The SDP proposition

Security policy flexibility is offered with fine-grained access control that can dynamically create and remove inbound and outbound access rules. Therefore, SDP minimizes the attack surface for bad actors to play with. Small attack surface results in a small blast radius. So less damage can occur. A VLAN has a relatively large attack surface, especially as the VLAN, contains different services. SDP eliminates the broad network access that VLANs exhibit.

SDP has a separate data and control plane. A control plane essentially sets up the controls necessary for data to pass from one endpoint to another. Separating the control from the data plane renders protected assets “black,” thereby blocking network-based attacks. You cannot attack what you cannot see.

The IP address; not a valid hook

We should be aware by now that IP addresses are lost in today’s hybrid environment. SDP provides a connection-based security architecture instead of an IP-based one. This allows for many things. For one security policies follow the user regardless of location. Let’s say you are carrying out forensics on an event 12 months ago for a specific IP. However, right now that IP address is a component in a test DevOps environment. Do you really care? Anything tied to IP is ridiculous as we don’t have a valid hook to hang things on for security policy enforcement.

Identity-driven network access control is more precise in measuring the actual security posture of the endpoint. Access policies tied to IP addresses cannot offer identity-focused security.

SDP enables the control of all connections based on the pre-vetting of who can connect and to what services. This means that if you do not meet this level of trust you can’t for example, access the database server but you can access public-facing documents. Users are granted access only to authorized assets preventing lateral movements that will probably go unnoticed when traditional security mechanisms are in place.

Information and infrastructure hiding

SDP does a great job of information and infrastructure hiding. The SDP architectural components ( the SDP controller and gateways ) are “dark” which provides resilience against both high and low volume DDoS attacks. A low bandwidth DDoS attack may often bypass traditional DDoS security controls. However, the SDP components do not respond to connections until the requesting clients are properly authenticated and authorized allowing only good packets through.

A good security protocol that can be used here is the single packet authorization (SPA). SPA gives the SDP components a default “deny-all” security posture. The “default-deny” can be achieved because if an accepting host receives any packet, other than a valid SPA packet, it assumes the packet is malicious. The packet will get dropped and a notification will not get sent back to the requesting host. This stops reconnaissance right at the door by silently detecting and dropping bad packets.

However, SPA can be subject to Man-In-The-Middle (MITM) attacks. If a bad actor can sniff a SPA packet, they have the opportunity to then establish the TCP connection to the controller or AH client. But there is another level of defense in that the bad actor is unable to complete the mutually encrypted connection (mTLS) without the client’s certificate. SDP brings in the concept of mutually encrypted connections, also known as two-way encryption. The usual configuration for TLS is that the client authenticates the server but TLS ensures that both parties are authenticated. This means that only validated devices and users can become authorized members of the SDP architecture.

We should also keep in mind that the SPA is not a security feature that can be implemented by itself to protect all. It has its benefits but does not take over from existing security technologies. SPA should work alongside them. The main reason for its introduction to the SDP world is to overcome the problems with TCP. TCP connects and then authenticates. With SPA you authenticate first and only then connect.

The world of TCP & SDP

With TCP when a client wants to access an application they must first set up a connection. There needs to be direct connectivity between the client and the applications. So this requires the application to be reachable and is carried out with IP addresses on each end.

Then once the connect stage is done, there is an authentication phase. Once the authentication stage is done we can pass data. Therefore, we have the connect, then authenticate and data pass stage. SDP reverses this.

The center of SDP is trust

In SDP, before the client is allowed to set up the connection we first must establish trust between the client and the application. The trust is bi-directional and happens between the client and the SDP service and the application to the SDP service.

Once trust has been established we move into the next stage which is the authentication. Once this has been established we can then connect the user to the application. This flips the entire security model and makes it more robust. The user has no idea of where the applications are located. The protected assets are hidden behind the SDP service which in most cases is the SDP gateway or some are calling this a connector.

Cloud Security Alliance (CSA) SDP

With the Cloud Security Alliance SDP architecture, we have a number of components:

Firstly, the IH & AH: which are the clients initiating hosts (IH) and the service accepting hosts (AH). The IH devices can be any endpoint device that can run the SDP software, including items such as user-facing laptops and smartphones. Many SDP vendors have IH browser-based solutions whereby no SDP client software is required. The IH as you might expect initiate the connections.

With an SDP browser-based solution, the user is using a web browser to access the applications and will only work with applications that can speak across a browser. So it doesn’t give you the full range of TCP and UDP ports but you can do many things that speak natively across HTML5. Most browser-based solutions don’t give you the additional security posture checks of assessing the end user device than an endpoint with the client installed.

The AH’s accept connections from the IH’s and provide a set of services protected securely by the SDP service. The AH’s are under the administrative control of the enterprise domain. They do not acknowledge communication from any other host, and will not respond to any non-provisioned requests. This architecture enables the control plane to remain separate from the data plane achieving a scalable security system.

The IH and AH devices connect to an SDP controller that secures access to isolated assets by ensuring that the users and their devices are authenticated and authorized before granting network access. After authenticating an IH, the SDP controller determines the list of AHs to which the IH is authorized to communicate too. The AH’S is then sent a list of IH’s that they should accept connections from.

Aside from the hosts and the controller we have the SDP gateway component that provides authorized users and devices with access to protected processes and services. The protected assets are located behind the gateway that can be architecturally positioned in multiple locations such as the cloud or on-premise. The gateways can exist in multiple locations in parallel.

Dynamic Tunnelling

It will be common in the real world to have a user with multiple tunnels to multiple gateways. It’s not a static path or a one to one relationship, its a user to application relationship. The applications can exist everywhere whereby the tunnel is dynamic and ephemeral. For a client to connect to the gateway, tests should be performed such as latency or SYN SYN/ACK RTT testing to determine the performance of the Internet links. This ensures that the application access path is always through the best gateway, improving application performance.

Keep in mind that the gateway only connects outbound on TCP port 443 (mTLS) and as it acts on behalf of the internal applications, therefore it needs access to the internal apps. As a result, depending on where you position the gateway, either internal to the LAN, private virtual private cloud (VPC) or in the DMZ protected by local firewalls, ports may need to be opened on the existing firewall.







Zero Trust: Single Packet Authorization | Passive authorization

Not everything in Software-Defined Perimeter (SDP) is new

Even though we are looking at disruptive technology to replace the virtual private network and offer secure segmentation. One thing to keep in mind with zero trust and software-defined perimeter (SDP) is that it’s not based on entirely new protocols. So we have reversed the idea of how TCP connects. Started with an authentication first then connect approach, but traditional networking and protocols still play a large part.

We still use encryption to ensure that only the receiver can read the data we are sending. We can, however, use encryption without authentication which validates the sender. However to stand any sort of chance in today’s world the two of them should go hand in hand. Attackers can circumvent many firewalls and secure infrastructure. As a result, message authenticity is a must for zero trust and without an authentication process, a bad actor could change, for example, the ciphertext without the reviewer ever knowing.

A key aspect of zero trust networks is to authenticate and authorize network traffic: i.e the flows between the requesting resource and the intended service. Simply securing communications between two endpoints is not enough. Security pros must ensure that each individual flow is authorized. This can be done by implementing a combination of security technologies such as Single Packet Authorization (SPA), Mutual Transport Layer Security (MTLS), Internet Key Exchange (IKE), and IP security (IPsec).

IPsec can use a unique security association (SA) per application in which only authorized flows are allowed to construct security policies. While IPsec is considered to operate at Layer 3 or 4 in the open systems interconnection (OSI) model, application-level authorization can be carried out with X.509 or an access token. There is also an enhanced version of TLS known as mutually authenticated TLS (MTLS) used to validate both ends of the connection. The most common TLS configuration is the validation which ensures that the client is connected to a trusted entity. But the authentication doesn’t happen the other way round so that the remote entity is communicating with a trusted client. This is the job of mutual TLS. As I said, mutual TLS goes one step further and authenticates the client.

The pre-authentication stage

You can’t attack what you cannot see. The mode that allows pre-authentication is Single Packet Authorization. UDP is the preferred base for pre-authentication because UDP packets by default do not receive a response. However, TCP and even ICMP can be used with the SPA.

Single Packet Authorization is a next-generation passive authentication technology, beyond what we previously had with port knocking which uses closed ports to carry out the identification of trusted users. SPA is a step up from port knocking. The typical port knocking scenario is for a port knocking server to configure a packet filter to block all access to a service, for example, the SSH service, until a specific port knock sequence is sent by a port knocking client. For example, the server could require the client to send TCP SYN packets to the following ports in order: 23400 1001 2003 65501.

If the server monitors this knock sequence, the packet filter reconfigures to allow a connection from the originating IP address. However, port knocking has its limitations which SPA addresses, SPA retains all of the benefits of port knocking but fixes the limitations.

What is Single Packet Authorization (SPA)

SPA was invented well over 10 years ago and was commonly used for superuser SSH access to servers where it mitigates attacks by unauthorized users. The SPA process happens before the TLS connection, mitigating any attacks targeted at the TLS ports.

As already mentioned SDP didn’t invent new protocols, it was more of a binding together of existing protocols. SPA used in the world of SDP was based on RFC 4226 HMAC-based One-Time Password “HOTP”. It is another layer of security and is not a replacement for the security technologies mentioned at the start of the post.

The first step in an attack is reconnaissance whereby an attacker is on the prowl to locate a target. This stage is easy to do and can be automated with tools such as Nmap. However, SPA ( and port knocking ) employs a default-drop stance that provides service only to those IP addresses that can prove their identity via a passive mechanism. No TCP/IP stack access is required to authenticate remote IP addresses. Therefore, Nmap cannot even tell that a server is running when protected with SPA, and whether the attacker has a zero-day exploit is irrelevant.

The idea around SPA is that a single packet is sent: based on that packet an authentication process is carried out. A key point to note is that there is nothing listening on the service itself so you have no open ports. For the SPA service to operate, there is not anything specifically listening. When the client sends a SPA packet, the packet will be rejected, but a second service identifies the SPA packet in the IP stack and then authenticates it.

If the SPA packet is successfully authenticated, the server will open a port in the server’s firewall which could be based on Linux iptables so that the client can establish a secure and encrypted connection with the intended service.

A simple SPA process flow

The SDP gateway protects assets and this component could be containerized and listens for SPA packets. In the case of an open-source version of SDP, this could be fwknop, which is a popular open-source SPA implementation.

When a client wants to connect to for example a web server, it sends a SPA packet. When the requested service receives the SPA packet, it will open the door once the credentials are verified. However, the service still does not respond to the request.

When the fwknop services receive a valid SPA packet, the contents of the packet will be decrypted for further inspection. Following the inspection, it will reveal the protocol and port numbers that the sender is requesting access to. The SDP gateway adds a rule to the firewall so that a mutual TLS connection to the intended service can be established. Once this mutual TLS connection is established, the SDP gateway removes the firewall rules and the service is invisible to the outside world.

Fwknop uses this information to open up firewall rules to allow the sender to communicate with that service on those ports. The firewall will only be opened up for a period of time which can be configurable by the administrator. Any attempts to connect to the service must know the SPA packet, and even if the packet can be recreated, the sequence number of the packet needs to be established prior to the connection. This is next to impossible to do considering the sequence numbers are randomly generated.

Once the firewall rules are removed, let’s say after 1 minute, the initial MTLS session will not be affected as it is already established. However, any other sessions requesting access to the service on those ports will be blocked. This permits only the sender of the IP address to be tightly coupled with the requested destination ports. It’s also possible for the sender to include a source port, enhancing security even further.

What can SPA offer

Let’s face it, robust security is hard to achieve. We all know that you can never be 100% secure. Just have a look at OpenSSH. OpenSSH was developed by some of the most security-conscious developers, and yet it occasionally contains exploitable vulnerabilities.

Even when you look at some of the attacks on TLS. We have already discussed the DigiNotar forgery in a previous post on zero trust networking but one that caused a major issue was the THC-SSL-DOS attack where a single host could take down a server by taking advantage of asymmetry performance required by the TLS protocol. Single Packet Authorization (SPA) overcomes many existing attacks and combined with the enhancements of MTLS with pinned certificates creates a robust security model. SPA defeats many a DDoS attack as only a limited amount of server performance is required for it to operate.

SPA provides the following security benefits to the SPA-protected asset:

  1. SPA blackens the gateway and protected assets that sit behind the gateway. The gateway does not respond to any connection attempts until they have provided an authentic SPA. Essentially, all network resources are dark until security controls are passed.
  1. SPA also mitigates DDoS attacks on TLS. More than likely, TLS is publicly reachable on the internet running the HTTPS protocol that is highly susceptible to DDoS. SPA mitigates these types of attacks because it allows the SDP gateway to discard the TLS DoS attempt before entering the TLS handshake. As a result, there will be no exhaustion from targeting the TLS port.
  1. SPA assists with attack detection. The first packet to an SDP gateway must be a SPA packet. If a gateway receives any other type of packet, it should be viewed and treated as an attack. Therefore, the SPA enables the SDP to identify an attack based on a single malicious packet.

For a general overview of zero trust concepts and projects such as software-defined perimeter, you can check out my course on ZERO TRUST NETWORKING: THE BIG PICTURE. If you would like more specifics on Single Packet Authorization (SPA) and how it relates to Software-Defined Perimeter (SDP), please see my other Zero Trust course on SOFTWARE-DEFINED-PERIMETER (SDP)





Cyber security threat. Young woman using computer and coding. Internet and network security. Stealing private information. Person using technology to steal password and private data. Cyber attack crime

Zero Trust Networks: Certificates

The zero trust framework for networking and security is here for a very good reason. There is a variety of bad actors: ranging from the opportunistic and targeted, to state-level and all are well prepared to find ways to penetrate a hybrid network.

As a result, there is now a compelling reason to implement the zero trust model for networking and security. Software-defined perimeter (SDP) is heavily promoted as a replacement to the virtual private network (VPN) and in some cases firewalls for ease of use and end user experience. It also provides a solid security framework utilizing a dynamic tunnel of 1, per app to per user. This offers security at the segmentation of a micro level, providing a secure enclave for entities requesting network resources. These are known a micro-perimeters.

For a general overview of zero trust concepts and project such as SDP, you can check out my course on ZERO TRUST NETWORKING: THE BIG PICTURE.

Authentication, and Authorization

So when it comes to creating a zero trust network what are the ways to authenticate and authorize?

Well, firstly trust is the main element within a zero trust network. Therefore, mechanisms that can associate themselves with authentication and authorization to trusting at a device, user, application level are a must for zero trust environments.

When something presents itself to a zero trust network it is required to go through a number of security stages before access is granted. Essentially the entire network is dark, meaning that resources drop all incoming traffic by default, providing for an extremely secure posture. Building on this simple premise, a more secure, robust, and dynamic network of geographically dispersed services and clients can be created.

Before we go any further, it’s important to understand the difference between authentication and authorization. Upon examination of an end host in the zero trust world, we have a device and a user, which together form an agent.

The authentication of the device and the user is carried out first before agent formation. Authentication of the device will come first and secondly the user. After these steps, the authorization is performed against the agent. Authentication means confirming your own identity, while authorization means granting access to the system.

Generally, with most zero trust vendors, the agent is only formed once valid device and user authentication have been carried out. And the authentication methods used to validate the device and user can be separate. A device that needs to identify itself to the network can be authenticated with X.509 certificates, and a user can be authenticated by other means such as a setting from an LDAP server if the zero trust solution has that as an integration point. The authentication methods between the device and users don’t have to be tightly coupled providing flexibility.

X.509 certificates

IP addresses are used for connectivity, not for authentication and don’t have any fields to implement authentication. The authentication must be handled higher up the stack. So we need to use something else to define identity and that would be the use of certificates.

X.509 certificates are a digital certificate standard that allows identity to be verified through a chain of trust and is commonly used to secure device authentication. X.509 certificates can carry a wealth of information within the standard fields that can fulfill the requirements to carry very specific metadata. To provide identity and also bootstrap encrypted communications, X.509 certificates use two cryptographic keys, mathematically-related pairs consisting of a public and private key. The most common are RSA (Rivest–Shamir–Adleman) key pairs.

The private key is secret and held by the owner of the certificate and the public key as the names suggest are not secret, thereby distributed. The public key can encrypt the data that the private key can decrypt and visa versa. If the correct private key is not held it is not possible to decrypt data that was encrypted using the public key.

Private key storage

Before we start discussing the public key. Let us examine how we secure the private key. If bad actors get their hands on the private key, its lights out for device authentication.

Once the device presents a signed certificate one way to secure the private key would be to configure some access rights to the key. However, if a compromise occurs we are left in the undesirable world of elevated access exposing the unprotected key. By far the best way to secure and store device private keys is to use cryptoprocessors such as a trusted platform module (TPM).

The cryptoprocessor is essentially a chip that is embedded in the device. The private keys are bound to the hardware without being exposed to the systems operating system, which is by far more vulnerable to compromise than the actual hardware. TPM binds the software private key to the hard creating a very robust device authentication.

Public Key Infrastructure (PKI)

How do we ensure that we have the right public key? This is the role of the public key infrastructure (PKI). There are many types of PKI’s with certificate authorities (CA) being the most popular. In cryptography, a certificate authority is an entity that issues digital certificates.

A certificate can just be a pointless blank piece of paper unless it is somehow trusted. This is done by digitally signing the certificate to endorse the validity. It is the responsibility of the certificate authorities to ensure all details of the certificate are correct before signing it. PKI is a framework that defines a set of roles and responsibilities that are used to securely distribute and validate public keys in an untrusted network. For this, a PKI leverages a registration authority (RA).

You may be wondering what’s the difference between an RA and a CA?. The RA interacts with the subscribers for providing CA services. The RA is subsumed in the CA, which takes total responsibility for all actions of the RA. The registration authority is responsible for accepting requests for digital certificates and authenticating the entity making the request. This binds the identity to the public key that is embedded in the certificate, cryptographically signed by the trusted 3rd party.

However, all certificate authorities are not bulletproof from attack. Back in 2011, DigiNotar was at the mercy of a security breach. The bad actor took complete control of all eight of the certificate-issuing servers in which they issued rogue certificates that have not yet been identified. It is estimated that over 300,000 users had their private data exposed by rogue certificates. DigiNotar’s certificates are immediately blacklisted by browsers but it does highlight the issues of using a 3rd party.

While Public Key Infrastructure is used at large on the public internet backing X.509 certificates, it’s not recommended for zero trust networks. At the end of the day, when you think about it you are still using 3rd party for a pretty important task. For a zero trust approach to networking and security, you should be looking to implement a private PKI system.

If you are not looking for a fully automated process, you could also implement a temporary one-time password (TOTP). This allows for human control over the signing of the certificates. Keep in mind that a great deal of trust must be placed on whoever is responsible for this step.



Software-defined perimeter: Zero-Trust

There are many companies attacking the same problem by using SD-WAN and multiprotocol label switching (MPLS) based architectures. However, the application is changing which requires a shift in these architectures. Application developers and software as service providers want to take more control of their sessions.

The next generation of applications is mobile, in the cloud, software as a service (SaaS), and the internet of things (IoT) based. It is literally everywhere and does not stay in the walled garden of the enterprise. You could say it’s completely distributed but certainly not dark and hidden from the Internet.

Solutions are needed that focus on connecting the application endpoints together wherever they are and whatever they are allowed to do. What we are seeing is a new type of perimeter, some are calling this a software-defined perimeter. A perimeter that is built from scratch by the application and employs a zero-trust model.

The perimeter should now be at the application. This is already common in microservices environments where the application programming interface (API) is the perimeter but we should now introduce this to non containerized environments, especially when it comes to IoT endpoints.

Fundamentally, the only way to secure the new wave of applications is to a) have reliable end-to-end reachability and b) assume a zero-trust model. You have to assume that the wires are not secure. For this, you need to have the ability to integrate the security solution more deeply within the application.

A collaborative model is needed that tightly integrates with the application providing the required security and network path control. Previously the traditional model separates the application from the network. The network does what it wants and the application does what it wants. The application would simply throw its bits so to speak over the wire and hope that the wires are secure. The packets will eventually get to their destination.

You need a solution that works more closely with the application to make sure of the end-to-end security. This can either be done by installing client software on the mobile app or by using some kind of software developer’s kit (SDK) or API. SD-WAN vendors have done a great job of backhauling security to the cloud and responded to the market very well. However, security must now become a first-class citizen within the application.

You can’t rely on tunnels on the internet anymore. From the application, you need to take the packet, readdress, encrypt it and send it to a globally private network. This private network can provide all the relevant services by either using standard Pops with physical/virtual equipment or by using containerized packed forwarders that can be spun upon demand. Containerized packed forwarders sound that little bit more interesting.

Each session can then get distributed to find the best route where a number of routers can be spun up all over the globe. The packet forwarder is spun up on different networks and different autonomous systems (AS) in the world enabling the maximum number of diverse paths between point A and point B i.e. different backbone providers, different AS, peering, and routing agreements.

The application endpoint can then examine all those paths for their given session and direct the packet to the best-performing path. Within seconds if a path is showing unacceptable performance, the session can be changed to a different path. Performance metrics like jitter, latency, and packet loss should be analyzed in real-time. And throughput for certain applications. You can do a linear optimization from all those variables.

Essentially you should do cold potato routing on the private network as opposed to hot potato routing. Cold potato routing keeps the packets on the network for as long as possible to take advantage of all the required optimizations.

Ways to integrate with the application

You can start by integrating with the application IAM (identity, access, and management) structure and then define what the application is allowed to talk to. For example, the port and protocols enable the business policies to govern the network behavior of the application.

If a packet comes from the internet address towards let’s say an IoT endpoint in the home, it needs to be authenticated and authorized so it will fit the business policy. These endpoints could then be streamlined into a distributed ledger like a blockchain. All of a sudden with proper machine learning and collaborations, you may be able to identify some of the DDoS attacks before they create massive problems.

In some cases, the policies can be tied to hardware router trust i.e. the silicon. This is often seen in the IoT-connected car use case. The silicon itself is creating a unique identifier, not a defined identity but an immutable one. The identity is generated by the unique conditions of the silicon itself. In this case, you don’t care about the IP addresses anymore. As we move further with technology, we are becoming less reliant on the IP address.

Within the software, you need to include a certificate and public key infrastructure (PKI) system so now you have a bidirectional, authenticated, and authorized certificate exchange, so again you don’t care about the IP address itself as you are working at an upper level.

rsz_technology_focused_hubnw

Matt Conran | Network World

Hello, I have created a Network World column and will be releasing a few blogs per month. Kindly visit the following link to view my full profile and recent blogs – Matt Conran Network World.

The list of individual blogs can be found here:

“In this day and age, demands on networks are coming from a variety of sources, internal end-users, external customers and via changes in the application architecture. Such demands put pressure on traditional architectures.

To deal effectively with these demands requires the network domain to become more dynamic. For this, we must embrace digital transformation. However, current methods are delaying this much-needed transition. One major pain point that networks suffer from is the necessity to dispense with manual working, which lacks fabric wide automation. This must be addressed if organizations are to implement new products and services ahead of the competition.

So, to evolve, to be in line with the current times and use technology as an effective tool, one must drive the entire organization to become a digital enterprise. The network components do play a key role, but the digital transformation process is an enterprise-wide initiative.”

“There’s a buzz in the industry about a new type of product that promises to change the way we secure and network our organizations. It is called the Secure Access Service Edge (SASE). It was first mentioned by Gartner, Inc. in its hype cycle for networking. Since then Barracuda highlighted SASE in a recent PR update and Zscaler also discussed it in their earnings call. Most recently, Cato Networks announced that it was mentioned by Gartner as a “sample vendor” in the hype cycle.

Today, the enterprises have upgraded their portfolio and as a consequence, the ramifications of the network also need to be enhanced. What we are witnessing is cloud, mobility, and edge, which has resulted in increased pressure on the legacy network and security architecture. Enterprises are transitioning all users, applications, and data located on-premise, to a heavy reliance on the cloud, edge applications, and a dispersed mobile workforce.”

“Microsoft has introduced a new virtual WAN as a competitive differentiator and is getting enough tracking that AWS and Google may follow. At present, Microsoft is the only company to offer a virtual WAN of this kind. This made me curious to discover the highs and lows of this technology. So I sat down with Sorell Slaymaker, Principal Consulting Analyst at TechVision Research to discuss. The following is a summary of our discussion.

But before we proceed, let’s gain some understanding of the cloud connectivity.

Cloud connectivity has evolved over time. When the cloud was introduced about a decade ago, let’s say, if you were an enterprise, you would connect to what’s known as a cloud service provider (CSP). However, over the last 10 years, many providers like Equinix have started to offer carrier-neutral collocations. Now, there is the opportunity to meet a variety of cloud companies in a carrier-neutral colocation. On the other hand, there are certain limitations as well as cloud connectivity.”

“Actions speak louder than words. Reliable actions build lasting trust in contrast to unreliable words. Imagine that you had a house with a guarded wall. You would feel safe in the house, correct? Now, what if that wall is dismantled? You might start to feel your security is under threat. Anyone could have easy access to your house.

In the same way, with traditional security products: it is as if anyone is allowed to leave their house, knock at your door and pick your locks. Wouldn’t it be more secure if only certain individuals whom you fully trust can even see your house? This is the essence of zero-trust networking and is a core concept discussed in my recent course on SDP (software-defined perimeter).

Within a zero-trust environment, there is no implicit trust. Thus, trust must be sourced from somewhere else in order to gain access to protected resources. It is only after sufficient trust has been established and the necessary controls are passed, that the access is granted, providing a path to the requested resource. The access path to the resource is designed differently, depending on whether it’s a client or service-initiated software-defined perimeter solution.”

“Networking has gone through various transformations over the last decade. In essence, the network has become complex and hard to manage using traditional mechanisms. Now there is a significant need to design and integrate devices from multiple vendors and employ new technologies, such as virtualization and cloud services.

Therefore, every network is a unique snowflake. You will never come across two identical networks. The products offered by the vendors act as the building blocks for engineers to design solutions that work for them. If we all had a simple and predictable network, this would not be a problem. But there are no global references to follow and designs vary from organization to organization. These lead to network variation even while offering similar services.

It is estimated that over 60% of users consider their I.T environment to be more complex than it was 2 years ago. We can only assume that network complexity is going to increase in the future.”

We are living in a hyperconnected world where anything can now be pushed to the cloud. The idea of having content located in one place, which could be useful from the management’s perspective, is now redundant. Today, the users and data are omnipresent.

The customer’s expectations have up-surged because of this evolution. There is now an increased expectation of high-quality service and a decrease in customer’s patience. In the past, one could patiently wait 10 hours to download the content. But this is certainly not the scenario at the present time. Nowadays we have high expectations and high-performance requirements but on the other hand, there are concerns as well. The internet is a weird place, with unpredictable asymmetric patterns, buffer bloat and a list of other performance-related problems that I wrote about on Network Insight. [Disclaimer: the author is employed by Network Insight.]

Also, the internet is growing at an accelerated rate. By the year 2020, the internet is expected to reach 1.5 Gigabyte of traffic per day per person. In the coming times, the world of the Internet of Things (IoT) driven by objects will far supersede these data figures as well. For example, a connected airplane will generate around 5 Terabytes of data per day. This spiraling level of volume requires a new approach to data management and forces us to re-think how we delivery applications.”

“Deploying zero trust software-defined perimeter (SDP) architecture is not about completely replacing virtual private network (VPN) technologies and firewalls. By and large, the firewall demarcation points that mark the inside and outside are not going away anytime soon. The VPN concentrator will also have its position for the foreseeable future.

A rip and replace is a very aggressive deployment approach regardless of the age of technology. And while SDP is new, it should be approached with care when choosing the correct vendor. An SDP adoption should be a slow migration process as opposed to the once off rip and replace.

As I wrote about on Network Insight [Disclaimer: the author is employed by Network Insight], while SDP is a disruptive technology, after discussing with numerous SDP vendors, I have discovered that the current SDP landscape tends to be based on specific use cases and projects, as opposed to a technology that has to be implemented globally. To start with, you should be able to implement SDP for only certain user segments.”

“Networks were initially designed to create internal segments that were separated from the external world by using a fixed perimeter. The internal network was deemed trustworthy, whereas the external was considered hostile. However, this is still the foundation for most networking professionals even though a lot has changed since the inception of the design.

More often than not the fixed perimeter consists of a number of network and security appliances, thereby creating a service chained stack, resulting in appliance sprawl. Typically, the appliances that a user may need to pass to get to the internal LAN may vary. But generally, the stack would consist of global load balancers, external firewall, DDoS appliance, VPN concentrator, internal firewall and eventually LAN segments.

The perimeter approach based its design on visibility and accessibility. If an entity external to the network can’t see an internal resource, then access cannot be gained. As a result, external entities were blocked from coming in, yet internal entities were permitted to passage out. However, it worked only to a certain degree. Realistically, the fixed network perimeter will always be breachable; it’s just a matter of time. Someone with enough skill will eventually get through.”

“In recent years, a significant number of organizations have transformed their wide area network (WAN). Many of these organizations have some kind of cloud-presence across on-premise data centers and remote site locations.

The vast majority of organizations that I have consulted with have over 10 locations. And it is common to have headquarters in both the US and Europe, along with remote site locations spanning North America, Europe, and Asia.

A WAN transformation project requires this diversity to be taken into consideration when choosing the best SD-WAN vendor to satisfy both; networking and security requirements. Fundamentally, SD-WAN is not just about physical connectivity, there are many more related aspects.”

“As the cloud service providers and search engines started with the structuring process of their business, they quickly ran into the problems of managing the networking equipment. Ultimately, after a few rounds of getting the network vendors to understand their problems, these hyperscale network operators revolted.

Primarily, what the operators were looking for was a level of control in managing their network which the network vendors couldn’t offer. The revolution burned the path that introduced open networking, and network disaggregation to the work of networking. Let us first learn about disaggregation followed by open networking.”

“I recently shared my thoughts about the role of open source in networking. I discussed two significant technological changes that we have witnessed. I call them waves, and these waves will redefine how we think about networking and security.

The first wave signifies that networking is moving to the software so that it can run on commodity off-the-shelf hardware. The second wave is the use of open source technologies, thereby removing the barriers to entry for new product innovation and rapid market access. This is especially supported in the SD-WAN market rush.

Seemingly, we are beginning to see less investment in hardware unless there is a specific segment that needs to be resolved. But generally, software-based platforms are preferred as they bring many advantages. It is evident that there has been a technology shift. We have moved networking from hardware to software and this shift has positive effects for users, enterprises and service providers.”

“BGP (Border Gateway Protocol) is considered the glue of the internet. If we view through the lens of farsightedness, however, there’s a question that still remains unanswered for the future. Will BGP have the ability to route on the best path versus the shortest path?

There are vendors offering performance-based solutions for BGP-based networks. They have adopted various practices, such as, sending out pings to monitor the network and then modifying the BGP attributes, such as the AS prepending to make BGP do the performance-based routing (PBR). However, this falls short in a number of ways.

The problem with BGP is that it’s not capacity or performance aware and therefore its decisions can sink the application’s performance. The attributes that BGP relies upon for path selection are, for example, AS-Path length and multi-exit discriminators (MEDs), which do not always correlate with the network’s performance.”

“The transformation to the digital age has introduced significant changes to the cloud and data center environments. This has compelled the organizations to innovate more quickly than ever before. This, however, brings with it both – the advantages and disadvantages.

The network and security need to keep up with this rapid pace of change. If you cannot match the speed of the digital age, then ultimately bad actors will become a hazard. Therefore, the organizations must move to a zero-trust environment: default deny, with least privilege access. In today’s evolving digital world this is the primary key to success.

Ideally, a comprehensive solution must provide protection across all platforms including legacy servers, VMs, services in public clouds, on-premise, off-premise, hosted, managed or self-managed. We are going to stay hybrid for a long time, therefore we need to equip our architecture with zero-trust.”

“With the introduction of cloud, BYOD, IoT, and virtual offices scattered around the globe, the traditional architectures not only hold us back in terms of productivity but also create security flaws that leave gaps for compromise.

The network and security architectures that are commonly deployed today are not fit for today’s digital world. They were designed for another time, a time of the past. This could sound daunting…and it indeed is.”

“The Internet was designed to connect things easily, but a lot has changed since its inception. Users now expect the internet to find the “what” (i.e., the content), but the current communication model is still focused on the “where.”

The Internet has evolved to be dominated by content distribution and retrieval. As a matter of fact, networking protocols still focus on the connection between hosts that surfaces many challenges.

The most obvious solution is to replace the “where” with the “what” and this is what Named Data Networking (NDN) proposes. NDN uses named content as opposed to host identifiers as its abstraction.”

“Today, connectivity to the Internet is easy; you simply get an Ethernet driver and hook up the TCP/IP protocol stack. Then dissimilar network types in remote locations can communicate with each other. However, before the introduction of the TCP/IP model, networks were manually connected but with the TCP/IP stack, the networks can connect themselves up, nice and easy. This eventually caused the Internet to explode, followed by the World Wide Web.

So far, TCP/IP has been a great success. It’s good at moving data and is both robust and scalable. It enables any node to talk to any other node by using a point-to-point communication channel with IP addresses as identifiers for the source and destination. Ideally, a network ships the data bits. You can either name the locations to ship the bits to or name the bits themselves. Today’s TCP/IP protocol architecture picked the first option. Let’s discuss the section option later in the article.

It essentially follows the communication model used by the circuit-switched telephone networks. We migrated from phone numbers to IP addresses and circuit-switching by packet-switching with datagram delivery. But the point-to-point, location-based model stayed the same. This made sense during the old times, but not in today’s times as the view of the world has changed considerably. Computing and communication technologies have advanced rapidly.”

“Technology is always evolving. However, in recent time, two significant changes have emerged in the world of networking. Firstly, the networking is moving to software that can run on commodity off-the-shelf hardware. Secondly, we are witnessing the introduction and use of many open source technologies, removing the barrier of entry for new product innovation and rapid market access.

Networking is the last bastion within IT to adopt the open source. Consequently, this has badly hit the networking industry in terms of the slow speed of innovation and high costs. Every other element of IT has seen radical technology and cost model changes over the past 10 years. However, IP networking has not changed much since the mid-’90s.

When I became aware of these trends, I decided to sit with Sorell Slaymaker to analyze the evolution and determine how it will inspire the market in the coming years.”

“Ideally, meeting the business objectives of speed, agility, and cost containment boil down to two architectural approaches: the legacy telco versus the cloud-based provider.

Today, the wide area network (WAN) is a vital enterprise resource. Its uptime, often targeting availability of 99.999%, is essential to maintain the productivity of employees and partners and also for maintaining the business’s competitive edge.

Historically, enterprises had two options for WAN management models — do it yourself (DIY) and a managed network service (MNS). Under the DIY model, the IT networking and security teams build the WAN by integrating multiple components including MPLS service providers, internet service providers (ISPs), edge routers, WAN optimizer, and firewalls.

The components are responsible for keeping that infrastructure current and optimized. They configure and adjust the network for changes, troubleshoot outages and ensure that the network is secure. Since this is not a trivial task, therefore many organizations have switched to an MNS. The enterprises outsource the buildout, configuration and on-going management often to a regional telco.”

“To undergo the transition from legacy to cloud-native application environments you need to employ zero trust.

Enterprises operating in the traditional monolithic environment may have strict organizational structures. As a result, the requirement for security may restrain them from transitioning to a hybrid or cloud-native application deployment model.

In spite of the obvious difficulties, the majority of enterprises want to take advantage of cloud-native capabilities. Today, most entities are considering or evaluating cloud-native to enhance their customer’s experience. In some cases, it is the ability to draw richer customer market analytics or to provide operational excellence.

Cloud-native is a key strategic agenda that allows customers to take advantage of many new capabilities and frameworks. It enables organizations to build and evolve going forward to gain an edge over their competitors.”

“Domain name system (DNS) over transport layer security (TLS) adds an extra layer of encryption, but in what way does it impact your IP network traffic? The additional layer of encryption indicates controlling what’s happening over the network is likely to become challenging.

Most noticeably it will prevent ISPs and enterprises from monitoring the user’s site activity and will also have negative implications for both; the wide area network (WAN) optimization and SD-WAN vendors.

During a recent call with Sorell Slaymaker, we rolled back in time and discussed how we got here, to a world that will soon be fully encrypted. We started with SSL1.0, which was the original version of HTTPS as opposed to the non-secure HTTP. As an aftermath of evolution, it had many security vulnerabilities. Consequently, we then evolved from SSL 1.1 to TLS 1.2.”

“Delivering global SD-WAN is very different from delivering local networks. Local networks offer complete control to the end-to-end design, enabling low-latency and predictable connections. There might still be blackouts and brownouts but you’re in control and can troubleshoot accordingly with appropriate visibility.

With global SD-WANs, though, managing the middle-mile/backbone performance and managing the last-mile are, well shall we say, more challenging. Most SD-WAN vendors don’t have control over these two segments, which affects application performance and service agility.

In particular, an issue that SD-WAN appliance vendors often overlook is the management of the last-mile. With multiprotocol label switching (MPLS), the provider assumes the responsibility, but this is no longer the case with SD-WAN. Getting the last-mile right is challenging for many global SD-WANs.”

“Today’s threat landscape consists of skilled, organized and well-funded bad actors. They have many goals including exfiltrating sensitive data for political or economic motives. To combat these multiple threats, the cybersecurity market is required to expand at an even greater rate.

The IT leaders must evolve their security framework if they want to stay ahead of the cyber threats. The evolution in security we are witnessing has a tilt towards the Zero-Trust model and the software-defined perimeter (SDP), also called a “Black Cloud”. The principle of its design is based on the need-to-know model.

The Zero-Trust model says that anyone attempting to access a resource must be authenticated and be authorized first. Users cannot connect to anything since unauthorized resources are invisible, left in the dark. For additional protection, the Zero-Trust model can be combined with machine learning (ML) to discover the risky user behavior. Besides, it can be applied for conditional access.”

“There are three types of applications; applications that manage the business, applications that run the business and miscellaneous apps.

A security breach or performance related issue for an application that runs the business would undoubtedly impact the top-line revenue. For example, an issue in a hotel booking system would directly affect the top-line revenue as opposed to an outage in Office 365.

It is a general assumption that cloud deployments would suffer from business-impacting performance issues due to the network. The objective is to have applications within 25ms (one-way) of the users who use them. However, too many network architectures backhaul the traffic to traverse from a private to the public internetwork.”

“Back in the early 2000s, I was the sole network engineer at a startup. By morning, my role included managing four floors and 22 European locations packed with different vendors and servers between three companies. In the evenings, I administered the largest enterprise streaming networking in Europe with a group of highly skilled staff.

Since we were an early startup, combined roles were the norm. I’m sure that most of you who joined as young engineers in such situations could understand how I felt back then. However, it was a good experience, so I battled through it. To keep my evening’s stress-free and without any IT calls, I had to design in as much high-availability (HA) as I possibly could. After all, all the interesting technological learning was in the second part of my day working with content delivery mechanisms and complex routing. All of which came back to me when I read a recent post on Cato network’s self-healing SD-WAN for global enterprises networks.

Cato is enriching the self-healing capabilities of Cato Cloud. Rather than the enterprise having the skill and knowledge to think about every type of failure in an HA design, the Cato Cloud now heals itself end-to-end, ensuring service continuity.”

While computing, storage, and programming have dramatically changed and become simpler and cheaper over the last 20 years, however, IP networking has not. IP networking is still stuck in the era of mid-1990s.

Realistically, when I look at ways to upgrade or improve a network, the approach falls into two separate buckets. One is the tactical move and the other is strategic. For example, when I look at IPv6, I see this as a tactical move. There aren’t many business value-adds.

In fact, there are opposites such as additional overheads and minimal internetworking QoS between IPv4 & v6 with zero application awareness and still a lack of security. Here, I do not intend to say that one should not upgrade to IPv6, it does give you more IP addresses (if you need them) and better multicast capabilities but it’s a tactical move.

It was about 20 years ago when I plugged my first Ethernet cable into a switch. It was for our new chief executive officer. Little did she know that she was about to share her traffic with most others on the first floor. At that time being a network engineer, I had five floors to be looked after.

Having a few virtual LANs (VLANs) per floor was a common design practice in those traditional days. Essentially, a couple of broadcast domains per floor were deemed OK. With the VLAN-based approach, we used to give access to different people on the same subnet. Even though people worked at different levels but if in the same subnet, they were all treated the same.

The web application firewall (WAF) issue didn’t seem to me as a big deal until I actually started to dig deeper into the ongoing discussion in this field. It generally seems that vendors are trying to convince customers and themselves that everything is going smooth and that there is not a problem. In reality, however, customers don’t buy it anymore and the WAF industry is under a major pressure as constantly failing on the customer quality perspective.

There have also been red flags raised from the use of the runtime application self-protection (RASP) technology. There is now a trend to enter the mitigation/defense side into the application and compile it within the code. It is considered that the runtime application self-protection is a shortcut to securing software that is also compounded by performance problems. It seems to be a desperate solution to replace the WAFs, as no one really likes to mix its “security appliance” inside the application code, which is exactly what the RASP vendors are currently offering to their customers. However, some vendors are adopting the RASP technology.

“John Kindervag, a former analyst from Forrester Research, was the first to introduce the Zero-Trust model back in 2010. The focus then was more on the application layer. However, once I heard that Sorell Slaymaker from Techvision Research was pushing the topic at the network level, I couldn’t resist giving him a call to discuss the generals on Zero Trust Networking (ZTN). During the conversation, he shone a light on numerous known and unknown facts about Zero Trust Networking that could prove useful to anyone.

The traditional world of networking started with static domains. The classical network model divided clients and users into two groups – trusted and untrusted. The trusted are those inside the internal network, the untrusted are external to the network, which could be either mobile users or partner networks. To recast the untrusted to become trusted, one would typically use a virtual private network (VPN) to access the internal network.”

“Over the last few years, I have been sprawled in so many technologies that I have forgotten where my roots began in the world of the data center. Therefore, I decided to delve deeper into what’s prevalent and headed straight to Ivan Pepelnjak’s Ethernet VPN (EVPN) webinar hosted by Dinesh Dutt. I knew of the distinguished Dinesh since he was the chief scientist at Cumulus Networks, and for me, he is a leader in this field. Before reading his book on EVPN, I decided to give Dinesh a call to exchange our views about the beginning of EVPN. We talked about the practicalities and limitations of the data center. Here is an excerpt from our discussion.”

“If you still live in a world of the script-driven approach for both service provider and enterprise networks, you are going to reach limits. There is only so far you can go alone. It creates a gap that lacks modeling and database at a higher layer. Production-grade service provider and enterprise networks require a production-grade automation framework.

In today’s environment, the network infrastructure acts as the core centerpiece, providing critical connection points. Over time, the role of infrastructure has expanded substantially. In the present day, it largely influences the critical business functions for both the service provider and enterprise environments”

“At the present time, there is a remarkable trend for application modularization that splits the large hard-to-change monolith into a focused microservices cloud-native architecture. The monolith keeps much of the state in memory and replicates between the instances, which makes them hard to split and scale. Scaling up can be expensive and scaling out requires replicating the state and the entire application, rather than the parts that need to be replicated.

In comparison to microservices, which provide separation of the logic from the state, the separation enables the application to be broken apart into a number of smaller more manageable units, making them easier to scale. Therefore, a microservices environment consists of multiple services communicating with each other. All the communication between services is initiated and carried out with network calls, and services exposed via application programming interfaces (APIs). Each service comes with its own purpose that serves a unique business value.”

“When I stepped into the field of networking, everything was static and security was based on perimeter-level firewalling. It was common to have two perimeter-based firewalls; internal and external to the wide area network (WAN). Such layout was good enough in those days.

I remember the time when connected devices were corporate-owned. Everything was hard-wired and I used to define the access control policies on a port-by-port and VLAN-by-VLAN basis. There were numerous manual end-to-end policy configurations, which were not only time consuming but also error-prone.

There was a complete lack of visibility and global policy throughout the network and every morning, I relied on the multi-router traffic Grapher (MRTG) to manual inspect the traffic spikes indicating variations from baselines. Once something was plugged in, it was “there for life”. Have you ever heard of the 20-year-old PC that no one knows where it is but it still replies to ping? In contrast, we now live in an entirely different world. The perimeter has dissolved, resulting in perimeter-level firewalling alone to be insufficient.”

“Recently, I was reading a blog post by Ivan Pepelnjak on intent-based networking. He discusses that the definition of intent is “a usually clearly formulated or planned intention” and the word “intention” is defined as ’what one intends to do or bring about.” I started to ponder over his submission that the definition is confusing as there are many variations.

To guide my understanding, I decided to delve deeper into the building blocks of intent-based networking, which led me to a variety of closed-loop automation solutions. After extensive research, my view is that closed-loop automation is a prerequisite for intent-based networking. Keeping in mind the current requirements, it’s a solution that the businesses can deploy.

Now that I have examined different vendors, I would recommend gazing from a bird’s eye view, to make sure the solution overcomes today’s business and technical challenges. The outputs should drive a future-proof solution”

“What keeps me awake at night is the thought of artificial intelligence lying in wait in the hands of bad actors. Artificial intelligence combined with the powers of IoT-based attacks will create an environment tapped for mayhem. It is easy to write about, but it is hard for security professionals to combat. AI has more force, severity, and fatality which can change the face of a network and application in seconds.

When I think of the capabilities artificial intelligence has in the world of cybersecurity I know that unless we prepare well we will be like Bambi walking in the woods. The time is now to prepare for the unknown. Security professionals must examine the classical defense mechanisms in place to determine if they can withstand an attack based on artificial intelligence.”

“When I began my journey in 2015 with SD-WAN, the implementation requirements were different to what they are today. Initially, I deployed pilot sites for internal reachability. This was not a design flaw, but a solution requirement set by the options available to SD-WAN at that time. The initial requirement when designing SD-WAN was to replace multiprotocol label switching (MPLS) and connect the internal resources together.

Our projects gained the benefits of SD-WAN deployments. It certainly added value, but there were compelling constraints. In particular, we were limited to internal resources and users, yet our architecture consisted of remote partners and mobile workers. The real challenge for SD-WAN vendors is not solely to satisfy internal reachability. The wide area network (WAN) must support a range of different entities that require network access from multiple locations.”

“Applications have become a key driver of revenue, rather than their previous role as merely a tool to support the business process. What acts as the heart for all applications is the network providing the connection points. Due to the new, critical importance of the application layer, IT professionals are looking for ways to improve the architecture of their network.

A new era of campus network design is required, one that enforces policy-based automation from the edge of the network to public and private clouds using an intent-based paradigm.

SD-Access is an example of an intent-based network within the campus. It is broken down into three major elements

  1. Control-Plane based on Locator/ID separation protocol (LISP),
  2. Data-Plane based on Virtual Extensible LAN (VXLAN) and
  3. Policy-Plane based on Cisco TrustSec.”

“When it comes to technology, nothing is static, everything is evolving. Either we keep inventing mechanisms that dig out new security holes, or we are forced to implement existing kludges to cover up the inadequacies in security on which our web applications depend.

The assault on the changing digital landscape with all its new requirements has created a black hole that needs attention. The shift in technology, while creating opportunities, has a bias to create security threats. Unfortunately, with the passage of time, these trends will continue to escalate, putting web application security at center stage.

Business relies on web applications. Loss of service to business-focused web applications not only affects the brand but also results in financial loss. The web application acts as the front door to valuable assets. If you don’t efficiently lock the door or at least know when it has been opened, valuable revenue-generating web applications are left compromised.”

“When I started my journey in the technology sector back in the early 2000’s the world of networking comprised of simple structures. I remember configuring several standard branch sites that would connect to a central headquarters. There was only a handful of remote warriors who were assigned, and usually just a few high-ranking officials.

As the dependence on networking increased, so did the complexity of network designs. The standard single site became dual-based with redundant connectivity to different providers, advanced failover techniques, and high-availability designs became the norm. The number of remote workers increased, and eventually, security holes began to open in my network design.

Unfortunately, the advances in network connectivity were not in conjunction with appropriate advances in security, forcing everyone back to the drawing board. Without adequate security, the network connectivity that is left to defaults is completely insecure and is unable to validate the source or secure individual packets. If you can’t trust the network, you have to somehow secure it. We secured connections over unsecured mediums, which led to the implementation of IPSec-based VPNs along with all their complex baggage.”

“Over the years, we have embraced new technologies to find improved ways to build systems.  As a result, today’s infrastructures have undergone significant evolution. To keep pace with the arrival of new technologies, legacy is often combined with the new, but they do not always mesh well. Such a fusion between ultra-modern and conventional has created drag in the overall solution, thereby, spawning tension between past and future in how things are secured.

The multi-tenant shared infrastructure of the cloud, container technologies like Docker and Kubernetes, and new architectures like microservices and serverless, while technically remarkable, increasing complexity. Complexity is the number one enemy of security. Therefore, to be effectively aligned with the adoption of these technologies, a new approach to security is required that does not depend on shifting infrastructure as the control point.”

“Throughout my early years as a consultant, when asynchronous transfer mode (ATM) was the rage and multiprotocol label switching (MPLS) was still at the outset, I handled numerous roles as a network architect alongside various carriers. During that period, I experienced first-hand problems that the new technologies posed to them.

The lack of true end-to-end automation made our daily tasks run into the night. Bespoke network designs due to the shortfall of appropriate documentation resulted in one that person knows all. The provisioning teams never fully understood the design. The copy-and-paste implementation approach is error-prone, leaving teams blindfolded when something went wrong.

Designs were stitched together and with so much variation, that limited troubleshooting to a personalized approach. That previous experience surfaced in mind when I heard about carriers delivering SD-WAN services. I started to question if they could have made the adequate changes to provide such an agile service.”