Sometimes in order to move forward effectively, it’s good to take stock of where we’ve been. In this blog, we’ll review a concept that has been foundational to networking and cybersecurity from the beginning: the session. Why focus on the session? As the philosophy of Zero Trust is adopted more broadly in the security industry, it’s important to understand the building blocks of access. The session is a fundamental component of access to any resource.  

To get things started, let’s start with a definition. A simple definition of a session might be: “a period of time devoted to a particular activity.” Not so bad, but the complexity for internet and network security springs from scoping the “particular activity.”  

The internet exists on top of a standardized suite of protocols that govern how data can be transmitted or exchanged between different entities. This suite, now generally referred to as the TCP/IP stack, is comprised of four distinct layers that delineate how data flows between networked resources. This is where the scoping of a session becomes obscure. The “particular activity” could refer to the network layer, which is responsible for establishing communications between the actual physical networks. Or, perhaps the activity refers to the Internet layer, which ensures the packets of data reach their destinations across network boundaries. The activity could also be the transport layer, responsible for the reliability of end-to-end communication across the network. It could also be referencing the application layer, the highest layer of the TCP/IP stack, which is responsible for the interface and protocols used by applications and users. For the familiar, these layers were originally defined in the OSI model.  

This layering framework works well for establishing the distinct session types and how we can begin to protect them.  However, the rise of cloud-based services means we must now also look at how sessions are defined in relation to the cloud — especially as we look to provide security and access controls.  At the application layer, we now have client devices with web browsers and applications that communicate to a cloud service.  Additionally, cloud services can be one or a combination of SaaS, PaaS and IaaS, each defining their own session and thus access.   

With all the different classes of sessions, there are different mechanisms and protocols by which authentication and authorization are employed to eventually provide that access.  All sessions use some type of account or credential to authenticate and evaluate a set of variables to determine authorization or access.  Some of these variables may also be similar across different sessions. For example, an enterprise may evaluate the device’s security posture (e.g. it is running the latest OS patches) as a variable to grant access at both the network and application layer. Similarly, the same username and password may be used across different session layers.   

However, each layer might also use distinct and specific variables to evaluate the appropriate access level.  For instance, the network interface layer may want to ensure cryptographic compliance of the network interfaces. A cloud service may evaluate geographical or regional compliance.  The common practice today is to have every session layer act alone to make its own access decision.  

Let’s take a step back and review.  

• We’ve established that there are many types of sessions, and the definitions are only expanding as cloud services become more prominent.  
• We’ve established that securing each type of session is important, yet in most cases each distinct session is evaluating a Venn diagram of variables, some common across session types, yet others specific to a particular session definition.  
• Finally, each session layer typically makes its own access evaluation. 

Now, let’s explore something new: what if the variables and access evaluation outcomes were shared seamlessly across session layers? 

What if recent network context and activity were used to inform cloud access decisions? Or, recent user access decisions across the network layers be used to inform cloud application controls?  Think about the enhanced resilience provided if network-based risk signal like packet information could be appropriately mapped and shared with the cloud application layer. Sharing information across session boundaries provides more robust fulfillment of Zero Trust principles by striving to evaluate security context as holistically as possible at the time of access.  

In order to build a future where security decisions are informed by broader and continuous context, we’ll need tools and protocols that help us bridge tools and map data across them.  To provide improved access and security, both the bridge and the correct mapping must be in place.  It’s one thing to get the data transferred to another tool, it’s quite another to map that data into relevance for the new tool. For example, how do we map a privileged application credential to a device? And, then how do we map relevant context across systems?  

The good news is that work is starting to enable a future where regardless of session definition, security context can be mapped and shared. Protocols such as the Shared Signals and Events and the Open Policy Agent are evolving to enable timely and dynamic signal sharing between tools, but they are nascent and broader adoption is required.  Cisco has already contributed a technical reference architecture as a guide for Shared Signals and Events. We hope that by accelerating the adoption of these standards the industry gets one step closer to actively sharing relevant security context across OSI layers. While the road ahead won’t be easy, we think the sharing signals will make for a more resilient and robust security future.  

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn