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.
