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.

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.

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

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.

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).

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.

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.

• 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).