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 complicated1 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.2 “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.
