From the Blogosphere
Control the Flow for Security | @CloudExpo #Cloud
Why is TCP/IP great for networking but problematic for security?
By: Mark Hoover
Mar. 17, 2016 04:00 PM
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:
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
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
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:
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 IPD respectively. 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
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?"
Software Defined Perimeters (SDP): secure, simple
In SDP, applications, services, and servers are isolated from users by an SDP 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 SDP Controller. Endpoints desiring connectivity to a destination protected by an SDP Gateway don't bother to send a connection request to that destination. Instead they "apply" for connectivity to the SDP Controller, who 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 SDP Gateway dynamically configures the TCP Gateways to allow connectivity. The systems isolated and protected by the SDP gateways are then never exposed to:
SDP Controllers and Gateways are software entities and can be deployed with no topological restriction. Thus SDP 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).
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week