How Context Provides the Missing Piece of the Puzzle for Security Ops
When it comes to security, context is king. In our recent podcast with the team at The New Stack, we explored the importance of context when it comes to security. This post is a more in-depth analysis of some of these concepts we discussed.
To understand the impact of context, let’s consider an everyday use case: The simple callerID. You get a phone call, and you look at a phone number. Potentially, your phone has a local directory (let’s call it a context cache) and it maps the number to a name, and based on this mapping you decide whether to answer the call or not, or you can check the log later to figure out who called you. Indeed phones are becoming more intelligent, and they are trying to determine this mapping by looking at your email and other local information. This process is efficient enough to skip lots of unwanted conversations.
When we look at application security, microsegmentation, and all similar concepts, they are not much more than this simple concept of a callerID. They look at an IP address, through some local cache (configuration rules) they map it to a good or bad status, and they accept or reject traffic based on that. They are pretty much elaborate callerID management entities. Seems to work as long the caches are reasonably up-to-date.
Now, let’s go back to our callerID example. You get a phone call, and your local directory discovers that it is likely from your child’s school. You have to make a decision. Do I answer or not? But the fact that the caller is the school doesn’t have enough context. Is the school calling you because of a fundraising event? Are they calling you because they are looking for volunteers for the next field trip? Is the principal calling for an urgent issue? Is your child calling because of an emergency?
Without enough context, and depending on your demeanor you either answer the phone (permissive mode) because you are afraid that it is an emergency, or you let it go to voice mail (strict mode), and if it is an emergency they will leave a message.
Classic security works in a very similar way. IP addresses and networks are classified and lack context. Rules determine whether the call is always accepted or not, and logs will inform you if the connection should be taken and dropped because of a policy, a task that often requires complicated analysis.
Now one can argue that there are advanced devices out there that will look deep into the communication areas and try to “guess” patterns. That sometimes work, but most often does not, especially since all communications are moving to full encryption over TLS and giving out the private keys to the firewall and making man-in-the-middle attacks to your communications is not necessarily the best idea.
What if the communication model or callerID model could extend to include context? Let us assume for example that when someone calls you their call will have enough contextual information on where they are calling from, who is on the other line (your child or the principle), what reason are they calling for, and so on. Then when you receive the call, you can quickly make a decision whether you want to accept it or not.
Moreover, if your context is sent back, the caller can immediately make a decision on whether it is appropriate to talk to you. For example, if the principal is calling, is it you answering the phone or the child’s friend that skipped school, pretending to be you.
The same principle holds in the application security context. When there is a communication attempt between two entities if there is sufficient verifiable context about the identity of the entities, then security can make reasonable decisions with a higher level of confidence. This avoids false negatives or false positives and places strict controls over what can and cannot be done.
For example, let us consider two microservices that try to interact for some reason. If we have enough context about each service, like, where they are running; who activated the services; in which environment are they running; whether they have vulnerabilities; or any other context attribute and all this context is part of their identity, then an authorization system can use the full contextual information rather than just the fact that services A and B are trying to communicate. Essentially the identity of the service is not just a domain name or a name, but a set of attributes that capture the environment and run-time context of the service.
Indeed, this model of context is the Google security model for user access.
There are a couple of key issues that one must pay attention to. First, the entity that creates the contextual information cannot be the caller. In other words, there is a need for a third party that can understand the context and has the authority to authenticate it. Strong cryptographic techniques must be deployed not to allow spoofing of the context or replay of the context (think of the spoofed callerID issues we have all seen). Second, just an identity (an FQDN or a certificate is not enough). This would reduce the solution back to the simple caller ID that we have now. Having the full context of the application is what enables educated decisions and not “guessing.”
Essentially by adding context in communications, we allow a more accurate authorization process that simplifies infrastructure and operations significantly. Every entity is equipped with an authorization function, and every connection can carry sufficient verifiable context for other applications to make an informed decision on whether they want this communication to be established or not.
We have implemented a framework to support this contextual model of security, called Trireme. Trireme is a distributed framework where communication can be authorized based on verifiable context and not just identities, providing cryptographic means for creating and verifying identities. It’s open source, so check it out here.
