Control the Flow for Security

Control the Flow for Security

TCP/IP connectivity starts with a DNS look-up so that Endpoint A, seeking to establish a connection to Endpoint B, can determine B’s IP address. Not knowing when a connection request may be coming, Endpoint B has to continually listen for the arrival of such requests. Not even knowing who the requester is, Endpoint B must respond to the connection request to establish a TCP connection. Only then can Endpoint B seek more information from Endpoint A to try to establish its identity, authorization, and trust.

 
 This basic architecture has fueled hugely scalable TCP/IP networking. The problem is, it requires:
 
 Servers to be heavily advertised (DNS)Continual network connectivityServers to expose themselves to unknown users and devices by responding to TCP requests.
 
 

If you have a desire to be as susceptible as possible to network-based attacks, and to be fooled by anyone who has stolen credentials from an authorized user, this is the perfect formula.

  

Server enforced authorization leave servers vulnerable

 

To defend themselves, enterprises have tried to limit authorization, usually by mapping employees and other users into Active Directory Groups that define the applications they are allowed to access. The problems, from the standpoint of protection against network-based attacks, are:

 
 

Stolen credentials can still fool the system if based simply on username/passwordServers must engage with the prospective user – establish a TCP connection and then probably a TLS connection – before enough information can be obtained to determine whether the user is authorized or not.

 
 A lot of bad things can happen in that time frame, including SQL injection, OS or server vulnerability exploitation, connection hijacking. It leads to a lot of closed barn door situations where the horse has already escaped.

Speed bumps like firewalls and VPNs and NAC don’t slow the attacks

 Because of that, over the years, enterprise IT professionals have tried to put controls in place to create “speed bumps” in the network to slow down or stop attackers. The most common of these “speed bumps” are firewalls, VPNs, ACLs, and VLANs.
 
 Network Address Translation (NAT) has been used to create enterprises networks that operate solely in their own private address space, which also enables the deployment of internal DNS servers for internal applications.
 
 

Commonly, they are deployed at the traditional perimeter: the LAN/WAN boundary. This means they are mostly about controlling access to remote users. In this case, deployments have been problematic:

  

Tunneled VPN access provides broad LAN connectivity. Creating and maintaining ACLs to limit such access is complex, difficult to maintain, and still results in a large attack surface as the external user must be connected to basic corporate network services (such as DNS, DHCP, software update, and system monitoring).Through phishing and other techniques, attackers have now compromised systems within the internal corporate network, effectively parachuting “behind” the perimeter defenses, rendering them useless.

 
 An attempt to address these realities have been made via Network Access Control (NAC).
 

When fully deployed, NAC moves the authentication process into the network as a way to prevent unauthorized users from ever seeing or connecting to servers for which they are not authorized to access. NAC is a very promising tool, but still suffers from some unfortunate realities.

NAC can be complex to deploy. For that reason, the granularity of a NAC decision is often just to put an authorized user on one of three different networks (VLANs) – internal corporate network, guest network, quarantine network (used to update software).

 
 To execute greater granularity requires the configuration and maintenance of a complex set of Access Control Lists (ACLs), which are basically a stack of IP address/port white list and black list rules. You could, for instance, limit user A on IPA from connecting to anything but servers B, C, and D of IPB, IPC, and IPDrespectively. But, as you can probably imagine, trying to configure this list for all users for all servers for all circumstances is untenable.
 
 The expanding enterprise “perimeter” promises more complexity, less security
 

There is an even bigger issue today that affects the viability of all these network “speed bump” approaches to security. Where do you put the speed bumps? The assumption with all of these controls is that the enterprise owns and controls the network path to the servers they want to protect. That was a great 1992 assumption. Maybe even 2002. In those days, pretty much all enterprise applications were run from within the enterprise network, accessed by users who were either local or backhauled over the corporate WAN to access the applications.

 
 Is that true now?
 
 Many apps have moved to SaaS or to Cloud Service Providers. Many companies are “untethering” their remote sites and de-commissioning their traditional MPLS or site-to-site VPNs. There is also a growing trend towards wireless networks bought as-a-service and even Layer 2 switches in the cloud. As these trends gain greater momentum, just where would enterprises “plug-in” these network-based “speed-bumps?”
 
 

Indecium PrecisionAccess(TM): Next Generation Access Control

 

My company, Indecium, has created a next generation access control to address all of the issues cited above. PrecisionAccess is Indecium‘s solution based on a new protocol, software-defined perimeter, promoted by Cloud Security Allinace (CSA). PrecisionAccess does not attempt to regulate traffic at the network level. It operates at the TCP level, which means it can be deployed anywhere and is transparent to network-level issues such as addressing, ownership, changing topologies, etc. Since data can’t flow unless a TCP connection is established, PrecisionAccess enables an enterprise to completely control who gets to connect to what over their entire extended enterprise network.

  

In PrecisionAccess, applications, services, and servers are isolated from users by a PrecisionAccess (PA) Gateway, which is a dynamically configured TCP Gateway. The Gateway rejects all traffic sent to protected servers unless users and endpoints are “pre-approved” by a third-party arbitrator. This third-party role is played by the PA Controller. Endpoints desiring connectivity to a destination protected by a PA Gateway don’t bother to send a connection request to that destination. Instead they “apply” for connectivity to the PA Controller, which determines if they are trusted or not.

 
 Trust verification involves device authentication, user authentication, and a set of context-based information that will continue to expand over time – location, BYOD vs. managed device, software posture, software integrity, and more. The goal is to evaluate overall trust as much as possible before allowing connectivity. If satisfied, the PA Gateway dynamically configures the TCP Gateways to allow connectivity. The systems isolated and protected by the PA gateways are then never exposed to:
 
 
  • Attackers who have stolen credentials

  • Unauthorized systems that may intend to exploit server or application vulnerabilities

  • Successful spear phishers trying to move laterally in a persistent search for access to sensitive data

  • Bad guys who, failing everything else, just want to deny service to others via bandwidth or resource starvation attacks

 

PA Controllers and Gateways are software entities and can be deployed with no topological restriction. Thus PrecisionAccess provides a powerful tool for enterprises to completely control the flow, no matter where the application is (internal or cloud), who the user is (employee or non-employee), or what the device is (managed or BYOD).