For more MovieLabs videos be sure to subscribe to our YouTube channel.

Introducing v1.3 of the Common Security Architecture for Production (CSAP)

As developers learn about implementing CSAP, their feedback helps us refine the CSAP architecture and we are now publishing CSAP version 1.3.

This round of changes is modest but we feel it makes the architecture cleaner and easier to understand how to implement it.

Below is a summary of the key changes from version 1.2:

The functions of the Asset Protection Service have been merged into the Authorization Service

There is no change in functionality because of this amendment but it is becoming clear that managing asset access authorizations is a core role of the authorization service and should not be a separate function.

The distinction between the supporting components Trust Inference and Continuous Trust Validation has been removed.

The market is showing that continuous trust validation is part of the trust engine in authentication systems that provide trust inference. The v1.3 architecture simply shows trust inference in the supporting security components. There is no change in functionality, we have simply removed what has become an unnecessary distinction.

The official Visual Language representation of CSAP has changed

We think our new representation makes it easier to understand that CSAP is a collection of services that provide the functionality necessary for CSAP to support the 3 levels of security. The three services of authorization, authentication and the authorization rule distribution that make up the CSAP core components are now shown as services within a CSAP infrastructure shape.

Similarly, we are representing the CSAP support components as seven services within an infrastructure shape (see the Visual Language to see how Infrastructure and Services are quickly identifiable with Shapes and Icons).

Put those together along with a couple of new Visual Language security icons and the new CSAP Overview diagram looks like this:

You will see that we are representing Global Security Management, that’s the source of security policies that are external to the production management/CSAP authorization set up, as a service.

In this diagram, production management is made up of workflow management and asset management. It’s illustrative of the two broad elements of production management that drive CSAP.

CSAP Part 5A has been updated to include the CSAP Zero-trust Foundation

CSAP is a zero-trust architecture for securing media production and the way to implement CSAP is to start with zero-trust. In a recent blog post we talked about all the different things that zero-trust could mean in our production context, the various “zero-trust” products being offered and we introduced the concept of the CSAP Zero-trust Foundation (ZTF). The CSAP ZTF is a zero-trust security model with a certain set of features necessary for building CSAP.

CSAP Part 5: Implementation Considerations is a living document that we plan to add to. We initially published Part 5A, 5B and 5C and with version 1.3, we have added an expanded version of the CSAP ZTF blog post to Part 5A. It’s worth a read if you’re sitting there wondering where to start on your CSAP journey.

Keep the Feedback Coming

We hope that reading this will encourage you to read the new versions which are available both as online documents on our documentation website and as downloadable PDF documents. Please reach out to MovieLabs if you have any questions about how to deploy any part of CSAP at csap@movielabs.com.

We’ll keep adding to the implementation considerations as and when we see a need, and we’ll publish the final part of the main document set, Part 6: Policy Description, at a later date.

Introducing Part 5 of the Common Security Architecture for Production (CSAP)

Today we are publishing Part 5: Implementation Considerations of the Common Security Architecture for Production (CSAP) v1.2. The CSAP architects were keen to design an architecture that did not have any boxes labelled “magic happens here,” and Part 5 offers some insight into our thinking and how we avoid them.

Part 5 conveys what the CSAP architects envisioned regarding the operational and technical implementation of CSAP, as well as lessons learned from implementing it. It’s not an implementation guide; its goal is to explain the architecture at the next level of detail to assist those who are actively implementing CSAP today.

CSAP Part 5 is divided into three parts to respond to where implementors are in their journey.

In Part 5A: Implementation Considerations – Starting Out we discuss how you get from here, a perimeter-based security system, to there, CSAP. The journey starts out by migrating to a zero-trust security (although it is probably more accurate to say zero-trust security philosophy), which is the entry point to CSAP. Recall that CSAP is a workflow-driven zero-trust security architecture for securing media production in the cloud, so the zero-trust philosophy comes first.

Part 5A then discusses what it means to get from zero-trust to CSAP levels 100, 200 and 300, The CSAP levels are not recommended practices or robustness. The levels describe required capabilities and functionality. Remember that a uniform CSAP level does not need to be applied across the entire production – some assets or services may be deemed to require level 100, some 200, and the most secure deemed to need level 300. CSAP is designed so that the decision as to which security level to apply can be made outside of CSAP, for example from risk analysis.

Part 5A wraps up looking at the core concept of trust, the more detailed version of our “Can I Trust You?” blog post.

Part 5B: Implementation Considerations – CSAP Core gets into the CSAP core security functions. A big part of this, and the place where every activity starts, is authentication. Part 5B addresses not only participant¹ authentication but also device and application authentication, and the core principle of mutual authentication. . The most common security when accessing a web service is Transport Layer Security (TLS) which is the S in https://. TLS allows the user’s to authenticate the web service. The user is authenticated by a secondary mechanism, in the simplest case a username and password. The two different mechanisms add to the complexity, but neither authenticates the user’s device. It’s just assumed that the user’s device can be trusted because the user is using it. CSAP requires mutual authentication which means that the service may require a mechanism to authenticate the user’s device, for example using mutual transport layer security (mTLS) rather than TLS.

Of course, there are alternatives to authenticating the device using certificates, for example, by evaluating the trustworthiness of the device. When a customer logs into one British bank, the bank’s service looks for remote control help desk software running on the customer’s device. This class of software is used by criminals as they seek to social engineer access to a victim’s account. If this software is detected, the customer is granted read-only access to their account but cannot do anything like authorize a payment. This is an example of extended device policy to add more security to the ecosystem.

In addition, Part 5A covers techniques for application authentication along with notes on

Part 5B has a section on the implementation issues surrounding the handling of authorization, including authorization policies and the creation and processing of authorization rules.

We conclude Part 5B with a section on the user experience drawing on the work done by the designers of Google’s BeyondCorp security architecture, and particularly the Explanation Engine. This is important because it is vital that the security is connected back to the user so that they know why they’ve just been denied something or are required to authenticate to access something.

The third of the Part 5 documents is Part 5C: Implementation Considerations – Approaches. In this document, we address some examples of how CSAP might be implemented in certain circumstances.

We start out examining techniques for implementing a zero-trust network at layers 2 and 3 such as Software-Defined Perimeters, and how a layer 7 (or layer 8 depending on your point of view) zero-trust network can be created using a service mesh.

Part 5C addresses access controls and how they can be managed. Spoiler alert: if you are using access controls to authorize a user’s access to a resource, you could add that user to the access control list for the resource, or you could add the user to a group that is authorized to access the resource.

We close Part 5C with a section on end-to-end encryption looking at both where it might be used and some considerations in implementing it. End-to-end encryption is important to realize the CSAP capability of operating securely on an untrusted infrastructure. We don’t get into the mathematics of cryptography, but we do look at the practicalities like key management.

Keep the Feedback Coming

We hope that reading this will encourage you to download CSAP Part 5, or the entire CSAP document package if you haven’t done so already – both are available here. Please reach out to MovieLabs if you have any questions about how to deploy any part of CSAP, including the new Part 5 and give us feedback as you rollout it out across your systems and environments. In 2023, we’ll be looking for Showcase examples of active CSAP deployments that will become working examples for others in the industry to learn from.

Trust

CSAP (the Common Security Architecture for Production) is a Zero Trust architecture but to understand zero-trust, we must first have a common understanding of what “trust” means. OK, so if we take the phrase “zero-trust” and stop there, we don’t need to understand what trust means because we don’t even have it – but that approach doesn’t get us anywhere. “Zero-trust security” means not trusting anything until it has been verified as something trustable and that seems like a better place to start.

Mayer, Davis, and Schoorman (1995) define trust as “the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other party will perform a particular action important to the trustor, irrespective of the ability to monitor or control that other party.” This is an excellent definition for our purposes because it hints at the consequences of trusting something that is not trustworthy.

In a debate on a security forum recently, one contributor was claiming that zero-trust is a paradox. The argument being you can’t know with absolute certainty that you can trust something. That’s true but then again, quantum mechanics says you can’t know with absolute certainty what state matter is in, but we don’t need to let either get in our way, unless we are planning to feed Schrödinger’s cat.

 Building Trust Relationships

To trust something, we need a trust relationship. There are two factors in creating a trust relationship.

1. Determining whether something can be trusted
2. Determining whether something claiming to be a trusted entity is indeed that entity and not an impostor

The first of these is a decision, and decision may not be the right word because ideally it should be reassessed continuously, based on factors that vary from one person to another, from one organization to another, from one situation to another, and it all comes down to risk assessment. As in Meyer, et al., the definition of trust is in the eye of the beholder.

Whether formally or unconsciously, risk assessment happens all the time. A threshold is set, factors evaluated, and a decision is made whether it’s above or below the threshold. That doesn’t mean it has to be done with a spreadsheet — we do it in the first second when we meet someone for the first time and whenever we get in our cars, we are subconsciously making a risk assessments like “it was fine last time I drove it.”

Determining whether an entity can be trusted is outside of the scope of CSAP, but the determination must be made. In cybersecurity, we need to be more formal. We decide to trust a server because of its endpoint security and the knowledge that all CVEs have been patched. We do that regardless of the security model.

The second of the two factors is the fundamental role of identity management. It is the thing that makes zero-trust work, and zero-trust means eschewing implicit trust. For example, implicit trust means trusting a device because of the network port or the VPN it is connected through. Explicit trust means not trusting a trusted user’s device unless it has been authenticated as the trusted device it purports to be.

Since trust is central to any zero-trust architecture, including CSAP, robust identity management is a prerequisite.

Trust and Authorization

If I say I trust you, I probably don’t mean I trust you to do everything. I might trust a cardiac surgeon to perform heart surgery (and would want to before they picked up a scalpel in my vicinity), but that doesn’t mean I’m going to trust them to do brain surgery on me. Trust has boundaries.

A trust boundary

In CSAP, trust boundaries are set by authorization. I verify you are the cardiac surgeon you claim to be (authentication) and I’m going to let you do my heart surgery (authorization). Brain surgery falls under deny by default.

So, we now have three factors:

1. Determining whether something can be trusted
2. Determining whether something claiming to be a trusted entity is indeed that entity and not an impostor
3. Determining whether the trusted entity is permitted to do what it’s just asked to do.

In CSAP terms, the first factor is part of the determination of whether something is to be included in workflows. Can a user contribute something to the workflow and have references been checked before they were hired?

When it comes to systems, it is the role of the same security tools we use today. For example, endpoint security is installed on a server, have all relevant CVEs been patched, etc.

The second factor is the role of the CSAP authentication service which uses some combination of identity management and certificate authorities.

The third factor is the role of the CSAP authorization service. Here, the question that must be answered is: how does the authorization service know what to authorize? After all, CSAP is deny-by-default and nothing useful is going to get done unless something is authorized. CSAP supports a wide range of options. At its simplest, authorization is created manually, isn’t very granular and lasts for a long time.

But CSAP is workflow-driven security, and its authorization rules can be created in response to requests from the workflow management. After all, what thing better knows what should be authorized in a part of the workflow than the entity that is determining what should be done in that part of the workflow? CSAP’s authorization rules can be as granular and specific as is required and can be supported by the implementation of workflow management and CSAP components. Trust me.

Introducing Part 4 of the Common Security Architecture for Production (CSAP)

Today we are publishing Part 4: Securing Software-Defined Workflows of the Common Security Architecture for Production (CSAP). It brings together two central threads of the MovieLabs 2030 Vision: CSAP and software-defined workflows (SDWs). Software-supported collaboration and automation are crucial to the future of scalable, multi-cloud workflows. This means that the security systems must work with, and in many cases, be driven by workflow software.

For this reason, CSAP is a workflow-driven security architecture for production in the cloud. It is a zero-trust architecture with a deny-by-default security posture and CSAP authorization rules that authorize activities. “Workflow-driven” means that security policies are created in response to what’s happening in the workflow, for example, the assignment of a task to an artist or the publication of dailies for review.

We use the term software-defined workflows (SDW) to broadly describe workflows where anyone designing a workflow has the ability to choose which tasks are used to perform specific functions, what assets and associated information those tasks communicate, which participants are involved, and what the rules are to advance or gate the process. Unlike workflows that are bound to specific hardware or rigid stacks of applications, SDWs are designed for change and the need to constantly modify and adapt workflows dynamically.

Multi-cloud and multi-org workflows are also a main driver for Part 4. The 2030 Vision assumes cloud infrastructures will be dynamic and shared across everyone and every organization working on production and therefore could be accessed by many organizations and independent contractors. This happens outside of the organization that controls the infrastructure, which contrasts with how private on-premises infrastructure is used and secured today. Extending the perimeter security models protecting private infrastructure to this cloud environment will be too complicated¹ for the agile security management necessary to respond fast enough to new and changing workflows. It will exacerbate the problem of security interfering with the creative process.

This is the reason CSAP exists. It is designed to work hand in hand with the new way of producing content and, and to do so without impinging on the creative process.

Workflows have some form of workflow management – the “thing” that is managing the workflow.² “CSAP Part 4: Securing Software-Defined Workflows” describes how workflow management and CSAP work together to secure workflows and protect their integrity.

Putting CSAP: Part 4 into Context

The lifetime of any workflow can be broken down into initialize and execute. Let’s take as an example that is part of a dailies workflow and see how Part 4 can be used to secure the steps in an example production workflow.

Figure 1 – A simple dailies creation workflow

Initialize is where everything is brought together. In our example, which is not atypical, initialization means the shooting schedule, crew selection, delivery specifications, camera specification, etc. Each step in workflow initialization is accompanied by initialization of parts of the workflow’s security. For example:

• When the production sets up the department: Accounts are created and roles defined for each crew member. Global policies are defined.
• When the production agrees on its workflows: Authorization policy templates are created. Policy Enforcement Points (PEPs) are provisioned.

The second step could be further broken down into inter-departmental and intra-departmental initializations.

Execution, what happens after someone hits “go” is often largely event driven and, once the department agrees on its workflow, adjustments are made to accommodate new requirements from the production management or to improve the workflow. In this case, execution would likely be event driven with steps that look like this:

Figure 2 – The events driving our dailies workflow example

The lifetime of authorization rules is set according to the security requirements of the production. In the case where the production has decided on more of a “least-privilege” approach using short-lifetime authorization rules, many of the events in the workflow could trigger security authorization changes. On the other hand, if a production uses long-lifetime authorization rules, the authorizations will be more static.

Let’s look at a couple possible examples from the dailies workflow above.

When camera and sound files arrive: The crew members tasked with syncing and uploading are authorized to access the files and workstations.

After the dailies have been approved and the files transcoded for creative review: Creative reviewers are authorized to stream the dailies. This type of authorization rule can be used to prevent premature delivery, meaning before review is completed.

These examples give some idea of how workflow management can drive security both at initialization and at execution. CSAP Part 4 goes into much more detail on how this workflow-driven security can be implemented.

SaaS and Workflow-Driven Security

SaaS offerings are also key components that must be integrated into software-defined workflows and their security. Part 4 considers the case of a closed service operated by a third party that has its own internal security and assets are held internally. The SaaS system is therefore responsible for ensuring that participants are authenticated for controlling their access to assets within the service as well as controlling any external access that it provides. In the context of a software-defined workflow that includes the SaaS system as one component, we have very similar needs for initialization and execution as in our examples above. If the service allows federation with external identity and access management system (IAM), some of these may be done through that IAM. And when a production requires short-lifetime authorization policies, the SaaS service needs to provide ways to support workflow-driven security policies, some of which may need to be set by systems external to the SaaS service. Part 4 double clicks on this use case.

Service Specific Authorizations

In considering authorization rules for different types of components, we’ve come to realize they often have different needs in how access controls may be scoped to particular portions of the service and to particular actions. File systems often use policies scoped to particular files or folders and actions based on CRUD (create, read, update, delete) operations. Messaging systems may scope policies to particular channels with actions such as create queue, read queue, send to queue, delete queue. Part 4 takes up  messaging and asset resolution systems as two examples of how scopes and actions can be defined for specific types of subsystems.

Keep the Feedback Coming

We hope that reading this will encourage you do download Part 4 and read about how CSAP secures software-defined workflows. Please reach out to MovieLabs if you have any questions about how to deploy any part of CSAP, including the new Part 4.

The next part of CSAP to be released is Part 5: Implementation Considerations. When we created CSAP, one of our goals was that it should not have any boxes that say “magic happens here.” Part 5 will give you insight into our thinking into the considerations we have about implementing CSAP, and it will be coming soon.

[1] Therefore, more likely to fail because complexity is the enemy of security.

[2] While a software-defined workflow will have some level of automation, our use of the term “workflow management” also applies to manual systems for scheduling work.

• CSAP Part 1: Architecture (v1.2)
• CSAP Part 2: Interfaces (v1.2)
• CSAP Part 3: Security Levels (v1.2)

These new versions come in response to comments from those organizations actively implementing CSAP in their workflows and systems. You talked, we listened!

We have changed how the architecture of the core security components is described and redistributed some of the functions.

We have also changed the term “Authorization Policy” (formerly known as “Dynamic Security Policy”) to “Authorization R.” In the revised CSAP architecture, the Policy Manager is collapsed into the Authorization Service and all the steps of Authorization Rule creation, including the validation against global security policies (those that come from, for example, an enterprise level and include the current security stance) happen within the Authorization Service. The Authorization Rules are then sent to the Authorization Rules Distribution Service which manages distribution to the Policy Enforcement Points.

A CSAP policy is a statement defining what is authorized or what must be denied, a CSAP rule describes a policy in a form understandable by the policy enforcement point to which it is directed. A policy template is the means to convert a policy into a rule and is often specific to the technology of the policy enforcement point.

Here is how v1.0 looked:

And this is v1.2:

The Authorization Rule is created using input from the same sources, but by moving the function of the policy service into the Authorization Service, implementation is simplified because the reconciliation of the Authorization Policy request and the global security policies happens as part of the Authorization Rule creation process rather than downstream.

We have also on CSAP delegation, describing how CSAP can be used across different organizations, each with a different level of security management autonomy.

Download CSAP Parts 1-3 v1.2 to see the updates in more detail, and you will also be able to read the expansion of Part 3 Security Levels, which adds detail to the levels and adds a section on automation.

We’ll continue to iterate CSAP with your input, so please continue to give us feedback as you learn and deploy.