Security used to be an explicit part of networking, as it was in IBM SNA and mainframe security. Can and should networks be the security focus again?
There are lots of ways bad actors could get into a network these days, and most of them will sooner or later involve accessing something they shouldn’t. Relationships with, and among, applications are called “sessions” – so, session control should be fundamental to security, right? It may surprise you to hear that session control is possible, highly effective, and rarely used.
One of the most challenging technical tasks I’ve ever faced was implementing middleware to let a minicomputer run a network of financial terminals, including some that used IBM’s SNA protocol. One of the features of SNA is that a central control point has to authorize all sessions, what’s sometimes called a “mother may I” approach. SNA was launched in 1974 and is still in use in a few places today. In all the years I surveyed and worked with enterprises, none ever reported a breach of application security on an SNA network. Could it be that networks, and session control, should be the focus of security? The SNA “Lone Ranger” rides again, and meets with mother-may-I mentality?
Nobody (even, I’m sure, IBM) believes we should return to SNA, but SNA did demonstrate that policy control over connectivity can revolutionize security. We actually have technology available today that brings SNA-like session control to IP networks, users, and applications. But of 338 enterprises who offered me comments on network security over the last 18 months, only 11 mentioned that technology. What is it, why hasn’t it swept the market, and what will it take to change that?
It’s not like we haven’t tried. Before IP took over networking via the Internet, we had a global standards initiative called the “OSI model” that defined a layered protocol that included (as the fifth layer) a “session layer,” where user and application relationships were created. But the Internet and IP, which came along before both SNA and OSI, didn’t have a session layer.
No session layer doesn’t mean no sessions. The TCP protocol is almost always used to connect users/applications on IP networks, but TCP fits at OSI Level 4 and doesn’t require any permission or coordination to set up a session. Real applications, users, hackers, and malware are all capable. Because sessions aren’t explicit, the network would have to detect them in order to control them, and that lack of session awareness is why we don’t have automatic session control in IP.
There are a number of session-based security add-ons that could support central, policy-based, control over user/application connectivity, but these require software changes on both sides of the session to implement. That makes them difficult to adopt, since in order for them to be effective, they’d need be rolled out across all client and server software in synchrony to avoid incompatibilities. And, of course, they’d have to be based on a standard, which unfortunately doesn’t really exist now and would be difficult to adopt in the face of what’s surely a base of millions of applications.
At this point, something within the network rather than within the client/server software would be easier. When SD-WAN came along, it was clear there was a benefit to “session routing” of packets rather than adding an SD-WAN header to every packet. With session routing, you pass policies along the network path telling SD-WAN nodes what to do with the packets that belong to each session. This requires you know what a session is, so some implementations of SD-WAN (Juniper’s Session Smart routers and Cato’s SD-WAN network, for example) have built on session awareness to add explicit session control, including the ability to bar sessions that are not authorized.
All good ideas have their issues, and active central session control surely has some. Users know from bitter experience with application software tools for access control that it can be a challenge just to know what sessions are authorized. How many policies would be needed for an enterprise, each of which would have to be established and maintained? Every hire, termination, transfer, and promotion would mean a policy change, and if software was changed in a way that impacted component connectivity, that would also have to be accommodated. Of 394 enterprises who offered comments on session security, 367 listed maintaining policies as the major problem. It’s particularly a problem if users can access applications from multiple devices.
Another problem, cited by 112 enterprises, is that a policy to allow session connections doesn’t necessarily validate the security of the party involved. Network-created session awareness conveys rights at the IP address level, so malware on the system could well inherit access rights granted to a legitimate application and user, and address spoofing might also be a risk. Even if the applications are changed to adopt explicit session control, hacking the application could allow malware to inherit session rights.
Security based on session control also fails if there are no recognizable sessions. Most applications connect via TCP, but there are some that do not, and there are also IP control packets (like the ever-popular “ping”) that aren’t part of a session but could, in theory, be used in an exploit or denial-of-service attack.
Finally, there’s the basic question of causality. Is SNA more secure because of explicit session control, or because the Internet doesn’t use SNA? An SNA network is a closed system. A pure “SNA endpoint,” one that wasn’t on the Internet, would be harder to hack, right? Yes, but far from impossible. In fact, those same SNA enterprises admit that most desktop systems used to access SNA applications also run IP.
Do all these issues invalidate the concept of session-based security? I don’t think so, because we still come back to the point that those remaining SNA users don’t report security issues with SNA. Furthermore, there’s a decent chance that addressing those issues might be a (dare we say?) legitimate application of AI.
We, and enterprises, already know that AI can be used to detect unusual traffic patterns, but of course constant AI surveillance of traffic is expensive. Suppose we used it instead to detect all the valid session relationships, and record them for session-based security? Suppose we used AI to analyze any attempts to establish a session not on the list, to quarantine the offender, or perhaps bar the session for review? Suppose our AI analysis also picked up non-session traffic and identified applications that generated it, and enterprises then introduced monitoring to detect it? That would simplify the day-to-day AI traffic analysis needed, and of course it’s always possible to have your central list of valid sessions available through an API so an application can be made to signal its desire to communicate and, if it’s valid, receive a session token to send to the session partner.
To many users, as I’ve noted, explicit session-based security seems like a lot of work, and cost. It is, though the amount can be reduced with the right approach. The real question is how the work and cost would compare to the work and cost of recovering from a security breach. No security strategy is as good as explicit positive control over user/application interactions…period. And we need to accept that to get security right.
