We all know that TCP/IP-based networking has proven to be hugely scalable and flexible. There are several reasons for that. One is the separation of responsibility between the network layer (IP) and the connection layer (usually TCP, sometimes UDP). The network layer focuses on efficiently moving packets from point A to point B on a large scale. The connection layer focuses on establishing and optimizing data transfer between point A and point B. Has it worked? Hundreds of millions of connected endpoints, moving steadily towards tens of billions, would tell you it has.
Up until now, the trick at the connection layer was to allow point A and point B to create a connection between them using a bi-directional handshake. That way, billions of different point A’s across the world can independently be connecting with billions of different points B’s across the world with no shared resource getting in the way other than the luck of the draw of common path elements (e.g. common network links, shared servers).
This has created great scale. But … it has also led to almost all of the network-related cybersecurity issues we struggle with today. Let’s illustrate why. Today, if Harry wants to connect to Sally, he will do that by looking up Sally’s publicly advertised address (in DNS) and sending a request to Sally to connect (a TCP SYN packet). When Sally receives that request, she has no information that it is coming from Harry. The requester could be her best friend or her worst enemy. The only way she has to determine that is to respond (with a TCP ACK packet) to continue the “handshake” that will ultimately create a TCP connection between the two. But at that point, Sally STILL doesn’t know that the person she just created a connection with is Harry, and whether she is on a path to useful collaboration or to security disaster. In the meantime, if Harry intends harm, Sally is providing him a lot of information. The mere act of responding to a TCP SYN tells Harry that she exists, is listening on at least one service port, and possibly what OS she is using. Additional hand-shaking is required to try to get Harry to prove he is who he claims to be, which just causes Sally to expose more information about herself and also gives Harry (or malware on Harry’s device he isn’t even aware of) the chance to exploit Sally’s vulnerabilities. And if someone stole Harry’s credentials he can continue the ruse indefinitely.
Now, I knw I am being a bit facetious here. What really happens with applications is that users interact with servers, not so much with one another. And I do know that servers don’t have best friends, but they do have a lot of enemies. And they are exposing themselves to those enemies in today’s world due to the direct bi-directional handshake required to set up TCP connections. And that does lead to continually degrading cybersecurity.
Let’s get back to Sally and Harry. Wouldn’t it have been much better if Sally’s Aunt Bessie knew Harry and Harry’s parents, deemed him to be a “nice boy” and chaperoned them to meet each other in a safe and pressure-free environment? Such brokering by a third party is much safer and dependable if done well. You might roll your eyes and say that takes all the romance, joy, excitement, and spontaneity out of creating human connections.
I am not sure I would even disagree with you on the above. But when it comes to Information Technology – I’ll trade off excitement for dependability and security any time.
This is why the concept of brokered or arbitrated connection management has taken hold in the form of the connectivity model. It is called Software Defined Perimeter (SDP) promoted by the Cloud Security Alliance. In SDP, applications, services, and servers are isolated from users (or other servers or IoT devices) by an SDP Gateway, which is a dynamically configured TCP Gateway. There is no connectivity that can be directly created via the traditional bi-directional handshake. The Gateway rejects all attempts at establishing a connection unless users and endpoints are “pre-approved” by a third party arbitrator. This third party “Aunt Bessie” 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 Aunt Bessie, who determines if they are a “nice boy” or not.
In the real world that might imply a bunch of questions about schooling, family, previous girlfriends, intentions, or critical stuff such as whether they are a Phillies fan or not. Actually these days, maybe blood and urine tests are required.
In the TCP/IP world it means 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, etc. 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 to “nice boys”. The systems isolated and protected by the SDP gateways are then never exposed to “bad boys” who have stolen credentials, intend to exploit server or application vulnerabilities, are trying to move laterally in a persistent search for access to sensitive data, or just want to deny service to others via bandwidth or resource starvation attacks.
Call it what you will; three-way handshake, arbitrated connection control, brokered connection management. Vocabulary may vary until the world agrees on some common terms. But no matter what you call it, one adjective applies – powerful.
