The best future is one that’s attainable. The most attainable thing is one that builds from the present. The best future that builds from the present builds from the best of the present. In networking, that means security. SDxCentral has a decent piece on a security-first slant to networking we can jump off from. The opening sentences are a good way to look at the issue: “The network and security landscape is undergoing a seismic shift. Outdated approaches are crumbling, vendors are consolidating and new players are emerging – it’s a game of 52 pick-up, but who’s going to hold all the cards in the end?” For our purposes here, though, the question is whether security shifts could create an opportunity for facilitating services.
The whole security value proposition is based on the Chicken Little theory of marketing. The sky is falling. Your IT infrastructure is doomed, and only I can save you. People will do a lot, buy a lot, to fend off the falling sky…at least until it gets to the CFO’s desk. Then the sky may look dark but still far away. Security is important, cost management is important, so a balance must be struck, and that’s a big issue for vendors, for operators, and for facilitating services.
The article’s point is very true in my view, and you can be sure of that because I’ve said so in several past blogs. The most fundamental element in security is the network. Get the network piece right and everything else is pretty easy. Get it wrong and you’ll need a lot of layers of stuff to break even, and even then it’s going to be a close call. That’s why the article is right in saying “Today’s solutions are no longer good enough.” We got it wrong at the network level.
Enterprises aren’t as sure about this as I am, or as the article’s author is. Of 428 enterprises with comments on security, only 177 said that the basic problem was rooted in the network. Only 228 said that the network could “significantly enhance” security. The rest believed in those layers, probably largely because they’d committed to that approach, couldn’t get approval for anything radical being done at the network level, or both. I’ve worked with a lot of enterprises over my career, and I think they’re right.
Security is intended to prevent unauthorized access, which in the real world means unauthorized connection. The Internet created an enormous security problem because it let everything connect pretty much indiscriminately with everything else. Prior to that, business networking was based on vendor-specific technology like IBM’s System Network Architecture (SNA). In SNA, nobody could connect to anything without express permission from the System Services Control Point (SSCP). Mother-may-I? The Internet was based on protocols designed for closed network missions, and the Internet opened the mission without changing the protocols, which we could have done, and could still do. But we’ll get into the “How?” piece of this when we’ve done a quick pass through the “Why not?”
For twenty years or so, companies have been working hard not only to avoid spending more on their networks, but to spend less. They’ve tried this approach and that, this vendor and that, and settled on something they want to be stable in the long term. Their NetOps people have gotten certifications for the stuff they use, they’ve modernized by buying newer versions of old things that have become unreliable or unmaintainable. All of this was done with little or no regard to the central question of closing the openness of their networks, and so no real progress was made on that front. What could be done now only matters if you can get approval to do it, and enterprises know that presenting a proposal to the CFO to rip and replace in the name of security isn’t going to be a popular move. So do vendors, so attractive makeup in the form of security add-ons beats plastic surgery in the product planning areas.
Time for (not to introduce euphonics) the “How” now. At about the time when enterprises were seeing their networks ossify, people were trying to harmonize the use of IP with the supposed-to-be-emerging technology of cell switching and Asynchronous Transfer Mode (ATM). A startup called Ipsilon came out with a way to use ATM virtual circuits to carry packets without IP routing. It was based on the general principle of a “persistent flow” and an old Internet RFC called “Next-Hop Resolution Protocol” or NHRP. The idea was to pick user/application relationships, or “sessions” and then run a virtual circuit across a non-broadcast multi-access (NBMA) network to the exit point closest to the destination. The goal was to be able to traffic manage key flows, and this evolved to become MPLS, leaving the abstract notions of persistent “session” flows (and what that might enable for security) on the cutting-room floor.
We can usually spot sessions pretty easily, since most of them are set up explicitly through TCP and can be detected by packet examination. Thus, we could identify when Thing A was trying to access Thing B. Suppose that, when such an attempt was identified, it triggered a query to the modern equivalent of that SSCP, to determine whether this session was allowed or not. Would that not provide a significant advance in security? Even examining DNS requests could help here; if Thing A wasn’t allowed to access Thing B, why tell Thing A what Thing B’s IP address was? Plus, a DNS request is usually a good indicator of the start of a session. And suppose there is an attempt to do something not allowed? Sure, you block it, but you could also log it, and any significant number of these attempts, or any change in the pattern, could be an indicator that some endpoint has gone over to the dark side. You can see some potential facilitating services here.
Session-based security should be fundamental, not only to enterprise networks (VPNs) but also to the Internet. You can see how a telco could be a credible mediator of the services involved, since we already trust them with a bunch of highly confidential information. We actually have a few examples of it, almost always in the implementation of SD-WAN and SASE, which create a kind of overlay or parallel network that has its own connection controls and rules. Only 19 enterprises of 173 who don’t already have one of these implementations has ever heard of the concept, so it’s obviously not promoted by vendors. The enterprises who either have it today or know of it are all ones who have or have considered SD-WAN. None said security was the driver of the decision, and none reported using it where SD-WAN wasn’t necessary, though it could be used anywhere.
Why isn’t it? It goes back, I believe, to three points. First, while central control of connection rights goes back, quite literally, to the last century (fifty years or so, in fact) applying the principles even indirectly to IP security through “session awareness” is only about five years old. Security layers is way older, and so we’ve been going down the add-on path for a while. Second, retrofitting session-based central access control to networks and applications today would be a pretty significant undertaking, something an enterprise would want a big vendor with deep pockets to be holding their hand through. Those vendors see an immediate hit on security-layer spending as soon as such a concept is presented, and a lot of competition in realizing the new approach. Finally, deciding explicitly who can connect to what requires maintaining a permissions-and-roles database, and that’s an effort. Thus…stay the course.
This is the challenge for facilitating services in security. You can’t have a facilitating service without something to facilitate. You can’t have that if the cost of generating the infrastructure at the telco level has to be augmented by the cost and risk of changes to the networks of the enterprises who want the retail security features. Thus, security isn’t the low apple for facilitating services despite the fact that it almost certainly is being seen that way. Security is an apple that you can reach only if you go out and buy a ladder, and to justify that ladder’s price, you need more than one apple. This opportunity has to follow on with something else. SD-WAN might have been it, but it’s probably too late now. Now, we probably need a new mission for enterprises, the very thing that drove prior peaks in IT spending growth. That’s what we’ll talk about tomorrow.
