Am I Authorized to Do That?

CSAP (the Common Security Architecture for Production) is a workflow driven Zero Trust security architecture designed for production workflows.

This is the third blog in our zero trust series, and in the first two we have explored the concept of trust and what it means in a zero trust architecture. The first two blogs are:

1. Can I trust you?
2. I don’t trust you, you don’t trust me, now what?

The subtitle of our third blog is “Why CSAP separates authentication and authorization” and the reason is because that is how zero-trust works! So, end of blog.

No, not really.

Let’s discuss why zero trust separates authentication and authorization.

To paraphrase a statement in the NIST zero trust architecture document, the goal of zero trust is to prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible. That means, authorized and authenticated entities (user, application, service, and device) can access the resources to the exclusion of all other entities (i.e., unauthenticated or unauthorized, which includes attackers). NIST SP 800-207, Zero Trust Architecture, goes on to say:

So separating authentication and authorization isn’t something we made up for CSAP; it’s fundamental to zero trust.

Let’s break that down. Clearly–and we discussed this in depth in the first blog in this series–you cannot trust anything that hasn’t been authenticated.

We love explaining security in parables. Here’s one for you: you live in a city, you’re alone in your home, and you just made yourself a cup of tea. The doorbell rings, and you open the front door to find three people in utility company overalls, who say you’ve got a problem with your gas supply. You hadn’t noticed anything because you just boiled water on the stove to make tea. Do you let them in? The short answer is “no!!!”. In fact, it’s difficult to think of a city where it was OK to open the door to start with! Letting them in, or even opening the front door, is implied trust. And if you let them in, you’re authorizing them to do anything they want in your home because there are three of them and one of you.

So, let’s deal with authentication first. You must check their ID and call the utility company to see if they are employees, why they were sent to your house and what the problem is that they came to fix. If you’re happy that they are real, it still doesn’t mean you should let them come in, and until you do, they’ve been authenticated but not authorized.

In our scenario, even if the utility company believes there is something wrong with your gas supply it can’t be in your home because you can’t smell gas and your stove works. Obviously, if you could smell gas, you wouldn’t have lit your stove. So that means you only need to give them access your gas meter which, as is the case in many suburban areas in United States, is attached to the outside of your home. You authorize them to enter the area beside your home where the gas meter is, but no more than that. You’ve let them inside the protect surface for your lawnmower but not the protect surface for your home.

However, let’s back up to the fresh cup of tea and the ringing doorbell. You look at your doorbell camera and recognize (i.e., authenticate) a close friend.

You let them in (i.e., authorize them to enter). In both cases (assuming the three people that visited you earlier were utility company employees), you have authenticated whoever is at the door, but your authorization only extends as far as is necessary or appropriate.

One more before we go back to cybersecurity. Let’s suppose you’ve been in bed for a week with a bad case of flu and your home is, quite reasonably in the circumstances, a mess and not the normal no-clutter environment you like to live in. Another friend arrives unannounced to visit. It’s someone you’d normally invite in, but in the circumstances, you explain through the intercom that you’re not up for visitors. What does this show? While you’d welcome this friend into your home (i.e., authorize entry) at one time, at another time you don’t want to (i.e., not authorize entry).

This illustrates something about managing authentication and authorization in a system: authentication is relatively static, whereas in dynamic environments such as film and TV production, it’s vital to be able to quickly and easily change who is authorized to do something. The NIST zero trust architecture uses the term “dynamic security policies” and CSAP uses the term “authorization policies”.

Take this one step further. Security policies are created to serve current needs for authorization. In CSAP, one source of that need is workflow management. That’s a different place than where identity is managed. The latter being an organization function, and normally it only changes during onboarding and off-boarding.

So, we hope you now understand why authentication and authorization are separated.

This is a functional or logical separation. It doesn’t necessarily mean there needs to be two distinct system.

For example, an identity and access management system (IAM) is in use that manages both user identity and user roles, and there is a storage pool with role based access management (RBAC) where access is controlled according the role assigned to a user. Workflow management wants an assistant editor to ingest a new set of dailies. It generates a request to grant (authorize) access to that assistant editor.

Without changing the IAM system or the access management method of the storage pool, or adding a new system, the assistant editor can be authorized to access the dailies in two ways:

1. The RBAC for the dailies is changed to include a role already assigned to the assistant editor by the IAM system.
2. A new role, one that already has access to the dailies, is assigned to the assistant editor.

The authorization service, which is simply acting on behalf of the workflow management, is using one of the two options to create a match between a role the user has and a role that can access the dailies.

Job done. And now back to that Cup of Tea…