I don’t trust you, you don’t trust me, now what?

We know you are keen to get the Common Security Architecture for Production (CSAP) up and running, but you may be wondering how you transition from perimeter security to CSAP. Let’s see if we can help.

Implementing a CSAP architecture can start with the CSAP Zero-Trust Foundation (CSAP ZTF). There is more than one way to approach zero-trust and the CSAP ZTF is a zero-trust implementation with particular characteristics necessary to fully implement CSAP. The requirement it places on the approach are not out of the ordinary and might be present in zero-trust implementations for other information technology system. CSAP ZTF it is not media production specific.

From the CSAP Zero-Trust Foundation, CSAP functionality is added on top to enable implementations to achieve CSAP level 100.

Why are we defining the CSAP Zero-Trust Foundation?

Zero-trust is not a well-defined term so if we say, “build CSAP on top of a zero-trust architecture” it isn’t helpful. In fact, there are many ways to define zero-trust, for example:

• Never trust, always verify. All network devices are untrusted until they have been authenticated, or;
• Zero Trust Architecture, NIST Special Publication 800-207 or;
• How your current or potential security vendor defines it.

Obviously the first definition is useful in as much as you have an idea what it means but at a network level. The NIST document is the best reference around but implementing it completely could, depending on your risk profile, result in something that is more complicated than is necessary for your needs. And the third one is one of the reasons we are defining the CSAP ZTF.

What is the CSAP Zero-Trust Foundation?

CSAP ZTF (because we love acronyms) is a zero-trust architecture implemented using the same off-the-shelf zero-trust solutions, for example those offered by leading cloud services providers, as any organization might use to implement zero-trust. Those solutions have a comprehensive array of features and a different selection might be made with different approaches.

Think of those solutions as a Tapas menu: usually you wouldn’t eat absolutely everything on it, but CSAP ZTF are like the dishes you just must have!

1. It is universally deny-by-default.

1. Nothing can take part in any workflow unless it has been appropriately authenticated. At minimum this applies to users, computer systems and services.
2. Nothing can take part in a specific workflow unless it has been authorized to conduct the activity.

2. It has separate authentication and authorization services. Unlike perimeter security models, an authenticated user might present a token to a service, but authorization to do anything goes directly to the policy enforcement point associated with that service. (See the diagram below.)
3. All authorizations are defined by security policies that are created and stored in an identifiable component of the system. This component becomes part of the CSAP Authorization Service.
4. The implementation assumes that the network is under the control of an intruder. The only exception would be if micro-segmentation is required for systems that have no options for intrinsic security, but the emphasis is on the word “micro.”
5. All network traffic and system usage is continuously analyzed for abnormal activity.

Note that isn’t a complete list of what is required in a zero-trust implementation. As we said, we’re just making sure you include the recommended items on the Tapas menu.

Security Is Controlled by Policies

A zero-trust security implementation is driven by security policies – there is no trust, meaning there are no default authentication or authorization defaults. Building a CSAP ZTF means having an identifiable point or points that are the source of the security policies that say what can be authorized to do what. These policies are of the type “allow,” meaning they permit activity – there is no need in zero-trust for policies that deny an activity since zero-trust is deny-by-default¹.

As you design your zero-trust implementation, the thread that holds it together is the policies.

Authentication and Authorization Are Not the Same Thing

In the first blog post in this series, Can I Trust You? we examined the two components of trust:

• Trustworthiness: determining if you can trust something
• Authentication: determining whether something is the trusted thing it claims to be

The first is a decision that you make using criteria that you create or take from other realms. The second is part of the security architecture and involves the presentation and validation of credentials.

In this first blog post in this series, we described a trust boundary² in this way “if something is authenticated it is trusted within that boundary but not (necessarily) outside of it.” In that blog post, our allegory was trusting a cardiac surgeon to perform heart surgery but not pulmonary surgery or brain surgery. The heart is inside the trust boundary, the pulmonary system and the brain are outside.

A trust boundary is a combination of authentication and authorization. In that example, all the medical staff are authenticated prior to being authorized to do something. Furthermore, the surgeon can’t just operate on any patient just because they have been authenticated. For a cardiac surgeon to perform surgery on you, someone (the patient for example) must allow (authorize) the surgeon to perform surgery. And, even though the surgeon has been authenticated, you do not allow (authorize) the surgeon to perform pulmonary or brain surgery. Let’s look at this as a workflow³.

1. A patient’s doctor suspects a patient has a heart problem, so the doctor refers the patient to a cardiologist meaning the cardiologist is authorized to treat the patient.
2. The cardiologist determines the patient needs surgery and authorizes heart surgery.
3. The patient is admitted to hospital and prepared for surgery. Before surgery can commence, the surgeon and the anesthetist must agree it can commence (again, authorization).

While this oversimplifies⁴ the way the medical profession works, what we have is a workflow laid down by hospital policies, and the authorization to perform each step comes from that being the next step in the care process. This has many of the same properties as a media workflow.

Going back to authentication for a minute, the hospital effectively operates a zero-trust security model inasmuch they don’t trust anyone to perform surgery just because they are in the hospital and wearing scrubs. The surgical staff must be authenticated one way or another.

This does not mean that authentication and authorization must be handled by different systems, although as CSAP functions are added doing so may prove more efficient, but the functions must be separable. For example, authenticating something should not provide an immutable set of authorizations as is the case with perimeter security when a user token from an identity and access management system includes access privileges. We will come to the reason for that.

Collapse the Protect Surface

John Kindervag, often credited with defining zero-trust, defines “protect surface” as the thing you are trying to protect, it is the attacker’s target, and it is where you put your protection measures. The protect surface is as close as possible around the thing that is protected. Kindervag, uses the Secret Service’s method for protecting the US President as an example.

Kindervag calls the uniformed agents and police officers standing along the street “security theater.”⁵ Their role is to protect against the low hanging fruit, for examples individuals in the crowd who charge toward the president’s vehicle and to intimidate anyone planning an attack. But the protect surface is around the president’s vehicle.

Applying this analogy to your system, you must define your protect surfaces, and you must make them as small as possible. You may decide your protect surface is around each server in your system, as is the case with the services in a mesh network, or you may decide that is impractical for part of your system and use network segmentation. If you use the latter strategy, the operative word is segmentation, and everything on that segment must have a reason for being there. For example, it’s unlikely that your data ingest systems need to be in the same network segment as your rendering nodes because they are at opposite ends of a VFX workflow.

Where Do I Start?

Regardless of what your security system is today, you start by formulating a plan to implement a zero-trust security solution that meets the needs of CSAP ZTF. There is a wealth of literature and solution providers out there to help you with implementing zero-trust and we have a short reading list at the end of this blog. To reemphasize the point, CSAP ZTF is not a media specific zero-trust implementation, it’s a zero-trust solution that might be implemented in any organization. CSAP ZTF has required features that not all zero-trust solutions might have.

Two factors are relevant to you existing security solution:

1. What can be kept and re-used?
2. What is my zero-trust deployment process?

On the first point, re-use isn’t just about (say) keeping your identity management system. It can go deeper, for example can I keep the same access controls on assets such as access control lists (ACLs) or role-based access control (RBAC)? Or is changing attribute-based access control (ABAC) or relationship-based access control (ReBAC) a better proposition?

On the second point, for example, if part of your infrastructure is on-premises, adequately secured, and does not need to interact with systems (external or internal) built on the principles of the MovieLabs 2030 Vision then you might decide to put that further out on your deployment schedule.

One more example that bridges the two points: if you are using microsegmentation for a small group of systems, and it is truly secure, then perhaps you keep it and focus on deploying a policy enforcement point at the point where the microsegment is accessed.

Map Your Workflows

Whether you are starting with an existing infrastructure protected by a traditional perimeter security approach or you are building new workflows on a cloud infrastructure, you need to start by mapping your workflows so that you understand who will be doing what tasks and with what assets and infrastructure. One of the advantages we have securing production over someone securing a corporate network is that our workflows are known and, at least to some extent, documented. You know how your dailies workflow works; you know how your VFX rendering workflow works. In the corporate environment, workflows are generally opaque⁶ to the IT department and require exploration before zero-trust can be implemented.

Architect Your Zero-Trust System and Create Policies

Once you have your protect surfaces defined, meaning you know exactly what you are protecting and they are as small as possible, and you know your workflows, you are ready to architect your system and deploy it.

Each policy must authorize as little as possible; to reduce complexity and increase manageability it is better to have many policies authorizing similar things than have a single multi-part policy that covers everything. Each policy should be only as complicated as is necessary to authorize a particular part of the workflow. For example, one policy might authorize access to assets by authorizing access to the storage location, and another policy authorizes access to a SaaS service.

It is likely that every policy will have components that are specific to a particular infrastructure, for example, a policy authorizing access to assets on one cloud provider’s infrastructure may be different from a policy that authorizes the same activity of a different cloud provider’s infrastructure. In CSAP we define two classes of polices:

• Authorization Policies are an abstract expression of what is authorized.
• Authorization Rules are Authorization Policies translated to the specific needs of a particular infrastructure.

It isn’t necessary to make that distinction when implementing the CSAP ZTF, however doing so will probably reduce the complexity of processing the policies at the policy enforcement point.

Policy Enforcement Points

A zero-trust architecture has policy enforcement points where a decision is made on whether something is authorized by a policy. In CSAP, we refer to policies in this context as Authorization Policies, and one of the parameters in those policies is the identity of the user (or more generally, the Participant) that is authorized to conduct the activity. The policy enforcement point accepts the user’s identity token and uses that in combination with the authorization policy to determine if the activity is authorized.

This differs from a traditional approach where the user’s token includes access claims (meaning what they are authorized to do). In CSAP, the authorization policy is not a property stored in the user’s record in the identity management system.

The two approaches can be seen in this diagram with the conventional approach on the left and the zero-trust approach on the right.

In a later blog post, we will describe how the CSAP architecture maps to the zero-trust model in NIST SP 800-207 (see reading list). We refer to NIST’s policy enforcement points and policy decision points collectively as policy enforcement points. All the functions are still there. We anticipated that there will be many ways that the policy enforcement point can be implemented. In some cases, the policy enforcement point is implemented using native security components of the infrastructure (for example, access controls in storage).

Monitor Everything

Everything must be monitored. You are looking for activity that is denied and authorized activity that is not consistent with previous activity or the workflows. Knowing what is legitimate allows the construction of trust inference where, for example, if a user’s credentials are used to access something from an unusual location, the attempt can be denied or subjected to a higher level of verification.

Similarly, it is important to know when legitimate activity is denied because of the absence of an authorization policy.

Lastly…

In this blog we have examined the CSAP ZTF which is a zero-trust architecture with a certain set of characteristics. These characteristics are common to other zero-trust system although not necessarily present in all “zero-trust” products. We’ll continue to expand this series with more useful implementation advice on CSAP, meanwhile if you have any questions or comments on this series, please reach out at info@movielabs.com.

AWS, Google Cloud Platform and Azure have useful documentation on using their security services to assist you in building zero-trust security into your cloud platform, however we believe that having a basic understanding of CSAP will help you deciding how to use those services to create the CSAP ZTF.

[2] Unrelated to a security perimeter.

[3] If this looks like a real medical workflow, it is a complete accident.

[4] An understatement!

[5] The term security theater was coined by computer security expert Bruce Schneier in his book Beyond Fear. He has applied the term to the TSA security measures introduced at airports following 9/11.

[6] The IT department provides email services but they don’t necessarily know how they are used other than to send messages to other people. For example, emails that recap decisions made in a meeting, sending email to yourself as a way of making notes, or filing emails in folders as a way of tracking different contract negotiations.