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

In this final part of our blog series on the current gaps between where are now and realizing the 2030 Vision, we’ll address the last two sections of the original whitepaper and look specifically at gaps around, Security and Identity, and Software-Defined Workflows. As with previous blogs in this series (see Parts 1 and 2) we’ll include both the gap as we see it, an example as it applies in a real workflow, and the broader implications of the gap.

So let’s get started with…

19. Inconsistent and inefficient management of identity and access policies across the industry and between organizations.

    Example: A producer wants to invite two studio executives, a director and an editor, into a production cloud service but the team has 3 different identity management systems. There’s no common way to identify the correct people to provide access to critical files or to provision that access.

    This is an issue addressed in the original 2030 Vision, which called for a common industry-wide Production User ID (or PUID) to identify individuals who will be working on a production. While there are ways today to stitch together different identify management and access control solutions between different organizations, they are point to point, require considerable software or configuration expertise, and are not “plug and play.”

20. Difficulty in securing shared multi-cloud workflows and infrastructure.

    Example: A production includes assets spread across a dozen different cloud infrastructures, each of which is under control of a different organization, and yet all need a consistent and studio-approved level of security.

    MovieLabs believes the current ”perimeter” security model is not sufficient to cope with the complex multi-organizational, multi-infrastructure systems that will be commonplace in the 2030 Vision. Instead, we believe the industry needs to pivot to a more modern ”zero-trust” approach to security, where the stance changes from ”try to prevent intruders” to every access to an asset or service is authenticated and checked for authorization. To that end, we’ve developed the Common Security Architecture for Production which is based on a Zero Trust Foundation, take a look at this blog to learn more.

21. Reliance on file paths/locations instead of identifiers.

    Example: A vendor requires a number of assets to do their work (e.g., a list of VFX plates to pull or a list of clips) that today tend to be copied as a file tree structure or zipped together to be shared along with a manifest of the files.

    In a world where multiple applications, users and organizations can be simultaneously pulling on assets, it becomes challenging for applications to rely on file names, locations, and hierarchies. MovieLabs instead is recommending unique identifiers for all assets that can be resolved via a service to specify where a specific file is actually stored. This intermediate step provides an abstraction layer and allows all applications to be able to find and access all assets. For more information, see Through the Looking Glass.

22. Reliance on email for notifications and manual processing of workflow tasks.

    Example: A vendor is required to do a task on a video asset and is sent an email, a PDF attachment containing a work order, a link to a proxy video file for the work to be done, and a separate link to a cloud location where the RAW files are. It takes several hours/days for the vendor to extract the required work, download, QC, and store the media assets, and then assign the task on an internal platform to someone who can do the work. The entire process is reversed to send the completed work back to the production/studio.

    By having non-common systems to send workflow requests, asset references and assign work to individual people, we have created an inherently inefficient industry. In the scenario above, a more efficient system would be for the end user to receive an automated notification from a production management system that includes a definition of the task to be done and links to the cloud location of the proxies and RAW files, with all access permissions already assigned so they can start their work. Of course, our industry is uniquely distributed between organizations that handle very nuanced tasks in the completion of a professional media project. This complicates the flow of work and work orders, but there are new software systems that can enable seamless, secure, and automated generation of tasks. We can strip weeks out of major production schedules simply by being more efficient in handoffs between departments, vendors and systems.

23. Monolithic systems and the lack of API-first solutions inhibit our progress towards interoperable modern application stacks.

    Example: A studio would like to migrate their asset management and creative applications to a cloud workflow that includes workflow automation, but the legacy nature of their software means that many tasks need to be done through a GUI and that it needs to be hosted on servers and virtual machines that mimic the 24/7 nature of their on-premises hardware.

    Modern applications are designed as a series of micro-services which are assembled and called dynamically depending on the process, which enables considerable scaling and also lighter weight applications that can deploy on a range of compute instances (e.g., on workstations, virtual machines or even behind browsers). While the pandemic proved we can have creative tasks running remotely or from the cloud a lot of those processes were ”brute forced” with remote access or cloud VMs running legacy software and are not the intended end goal of a ”cloud native” software stack for media and entertainment. We recognize this is an enormous gap to fix and will take beyond the 2030 timeframe to move all of the most vital applications/services to modern software platforms. However we need the next-generation of software systems to enable open APIs and deploy in modern containers to accelerate the interoperable and dynamic future that is possible within the 2030 Vision.

24. Many workflows include unnecessarily time consuming and manual steps.

    Example: A director can’t remotely view a final color session in real time from her location, so she needs to wait for a full render of the sequence, for it to be uploaded to a file share, for an email with the link to be sent, and then for her to download it and find a monitor that matches the one that was used for the grade.

    We could write so many examples here. There’s just way too little automation and way too much time wasted in resolving confusions, writing metadata, reading it back, clarifying intent, sending emails, making calls etc. Many of the technologies exist to fix these issues, but we need to redevelop many of our control plane functions to adopt to a more efficient system which requires investment in time, staff, and development. But those that do the work will come out leaner, faster and more competitive at the end of the process. We recommend that all participants in the ecosystem take honest internal efficiency audits to look for opportunities to improve and prioritize the most urgent issues to fix.

Phew!  So, there we have it. For anyone that believes the 2030 Vision is “doable” today, there are 24 reasons why MovieLabs disagrees. Don’t consider this post a negative, we still have time to resolve these issues, and it’s worth being honest about the great progress completed but also what’s still to do.

Of course, there’s no point making a list of things to do without a meaningful commitment to cross them off. MovieLabs and the studios can’t do this alone, so we’re laying down the gauntlet to the industry – help us, to help us all. MovieLabs will be working to close those gaps that we can affect, and we’ll be publishing our progress on this blog and on LinkedIn. We’re asking you to do the same – share what your organization is doing with us by contacting info@movielabs.com and use #2030Vision in your posts.

There are three specific calls to action from this blog for everyone in the technical community:

1. The implementation gaps listed in all parts of this blog are the easiest to close – the industry has a solution we just need the commitment and investment to implement and adopt what we already have. These are ones we can rally around now, and MovieLabs has already created useful technologies like the Common Security Architecture for Production, the Ontology for Media Creation, and the Visual Language.
2. For those technical gaps where the industry needs to design new solutions, sometimes individual companies can pick these ideas up and run with them, develop their own products, and have some confidence that if when they build them customers will come. Some technical gaps can only be closed by industry players coming together, with appropriate collaboration models, to create solutions that enable change, competition, and innovation. There are existing forums to do that work including SMPTE and the Academy Software Foundation, and MovieLabs hosts working groups as well.
3. And though not many issues are in the Change Management category right now, we still need to work together to share and educate how these technologies can be combined to make the creative world more efficient.

We’re more than 3 years into our Odyssey towards 2030. Join us as we battle through the monsters of apathy, slay the cyclops of single mindedness, and emerge victorious in the calm and efficient seas of ProductionLandia. We look forward to the journey where heroes will be made.

-Mark “Odysseus” Turner

In Part 1 of this blog series we looked at the Gaps in Interoperability, Operational Support and Change Management that are impeding our journey to the 2030 Vision’s destination (the mythical place we call “ProductionLandia”). In these latter parts we’ll examine the gaps we have identified that are specific to each of the Principles of the 2030 Vision. For ease of reference, the Gaps below are numbered starting from 9 (because we had 1-8 in Part 1 of the blog). For each Gap we list the Principle, a workflow example of the problem, and the implications for the Gap.

In this post we’ll look just at the gaps around the first 5 Principles of the 2030 Vision which address a new cloud foundation.

9. Limitations of sufficient bandwidth and performance, plus auto recovery from variability in cloud connectivity.

   Example: Major productions can generate terabytes of captured data per day during production and getting it to the cloud to be processed is the first step.

   Even though there are studio and post facilities with large internet connections, there are still many more locations, especially remote or overseas ones, where the bandwidth is not large enough, the throughput not guaranteed or predictable enough, such as to hobble cloud-based productions at the outset. Some of the benefits in cloud-based production involve the rapid access for teams to manipulate assets as soon as they are created and for that we need big pipes into the cloud(s), that are both reliable and self-healing. Automatic management of those links and data transfers is vital as they will be used for all media storage and processing.

10. Lack of universal direct camera, audio, and on-set data straight to the cloud.

    Example: Some new cameras are now supporting automated upload of proxies or even RAW material direct to cloud buckets. But for the 2030 Vision to be realized we need a consistent, multi-device on-set environment to be able to upload all capture data in parallel to the cloud(s) including all cameras, both new and legacy.

    We’re seeing great momentum with camera to cloud in certain use cases (with limited support from newer camera models) sending files to specific cloud platforms or SaaS environments. But we’ve got some way to go before it’s as simple and easy to deploy a camera-to-cloud environment as is it to rent cameras, memory cards/hard drives, and a DIT cart today. We also need support for multiple clouds (including private clouds) and or SaaS platforms so that the choice of camera-to-cloud environment is not a deciding factor that locks downstream services into a specific infrastructure choice. We’ve also included in the gap that it’s not just ”camera to cloud” but “capture to cloud” that we need, which includes on-set audio and other data streams that may be relevant to later production stages including lighting, lenses, and IOT devices. All of that needs to be securely and reliably delivered to redundant cloud locations before physical media storage on set can be wiped.

11. Latency between “single source of truth in cloud” and multiple edge-based users.

    Example: A show is shooting in Eastern Europe, posting in New York, with producers in LA and VFX companies in India. Which cloud region should they store the media assets in?

    As an industry we tend to talk about “the cloud” as a singular thing or place, but in reality of course it is not – it’s made up of private data centers, and various data centers which hyperscale cloud providers tend to arrange into different “availability zones” or “regions” which must be declared when storing media. As media production is a global business the example above is very real, it leads to the question – where should we store the media and when should we duplicate it for performance and/or resiliency? This is also one of the reasons why we believe multi-cloud systems need to be supported because it’s also possible that the assets for a production are scattered across different availability zones, cloud accounts (depending on which vendor has “edit rights” on the assets at any one time), and cloud providers (public, private and hybrid infrastructures). The gap here is that currently decisions need to be made, potentially involving IT systems teams and custom software integrations, about where to store assets to ensure they are available, at very low latency (sub 25 milliseconds round trip – see Is the Cloud Ready to Support Millions of Remote Creative Workers? for more details) for the creative users who need to get to them. By 2030 we’d expect some “intelligent caching’” systems or other technologies that would understand, or even predict, where certain assets need to be for users and stage them close enough for usage before they are needed. This is one of the reasons why we reiterate that we expect, and encourage, media assets to be distributed across cloud service providers and regions and merely ”act” as a single storage entity even though they may be quite disparate. This is also implies that applications need to be able to operate across all cloud providers because they may not be able to predict or control where assets are in the cloud.

12. Lack of visibility of the most efficient resource utilization within the cloud , especially before the resources are committed.

    Example: When a production today wants to rent an editorial system, it can accurately predict the cost, and map it straight to their budget. But with the cloud equivalent it’s very hard to get an upfront budget because the costs for cloud resources rely on predicting usage, which is hard to know including hours of usage, amount of storage required, data egress, etc.

    Creative teams take on a lot when committing to a show, usually with a fixed budget and timeline. It’s hard to ask them to commit to unknown costs, especially for variables which are hard to control at the outset – could you predict how many takes for a specific scene? How many times a file will be accessed or downloaded? Or how many times a database queried? Even if they could accurately predict usage, most cloud billing is done in arrears, and therefore the costs are not usually known until after the fact, and consequently it’s easy to overrun costs and budgets without even knowing it.

    Similarly, creative teams would also benefit from greater education and transparency concerning the most efficient ways to use cloud products. Efficient usage will decrease costs and enhance output and long-term usage.

    For cloud computing systems to become as ubiquitous as the physical equivalent, providers need to find ways to match the predictability and efficient use of current on-premises hardware, but with the flexibility to burst and stretch when required and authorized to do so.

13. Too few cloud-aware/cloud-native apps, which necessitates a continued reliance on moving files (into clouds, between regions, between clouds, out of clouds).

    Example: An editor wants to use a cloud SaaS platform for cutting their next show, but the assets are stored in another cloud, the dailies system providing reference clips is on a third, and the other post vendors are using a private cloud.

    We’re making great progress with getting individual applications and processes to move to the cloud but we’re in a classic ”halfway” stage where it’s potentially more expensive and time consuming to have some applications/assets operating in the cloud and some not. That requires moving assets into and out of a specific cloud to take advantage of its capabilities and if certain applications or processes are available only in one cloud then moving those assets specifically to that cloud, which is the the sort of “assets chasing tasks” from the offline world that this principle was designed to avoid in the cloud world. We need to keep pushing forward with modern applications that are multi-cloud native and can migrate seamlessly between clouds to support assets stored in multiple locations. We understand this is not a small task or one that will be quick to resolve. In addition, many creative artists used Mac OS and that is not broadly available in cloud instances and in a way that can be virtualized to run on myriad cloud compute types.

14. Audio post-production workflows (e.g., mixing, editing) are not natively running in the cloud.

    Example: A mixer wants to remotely work on a mix with 9.1.6 surround sound channels that are all stored in the cloud. However most cloud based apps only support 5.1 today, and the audio and video channels are streamed separately so the sync between the audio and the video can be “soft” in a way that it can be hard to know if the audio is truly playing back in sync.

    The industry has made great strides in developing technologies to enable final color (up to 12 bit) to be graded in the cloud, but now similar attention needs to be paid to the audio side of the workflows. Audio artists can be dealing with thousands, or even tens of thousands of small files and they have unique challenges which need to be resolved to enable all production tasks to be completed in the cloud without downloading assets to work remotely. The audio/video sync and channel count challenges above are just illustrative of the clear need for investment and support of both audio and video cloud workflows simultaneously to get to our “ProductionLandia” where both can be happening concurrently on the same cloud asset pool.

15. Lack of communication between cross-organizational systems (AKA “too many silos”) and inability to support cross-organizational workflows and access.

    Example: A director uses a cloud-based review and approval system to provide notes and feedback on sequences, but today that system is not connected to the workflow management tools used by her editorial department and VFX vendors, so the notes need to be manually translated into work orders and media packages.

    As discussed above we’re in a transition phase to the cloud, and as such we have some systems that may be able to receive communication (messages, security permission requests) and commands (API calls), whereas other systems are unaware of modern application and control plane systems. Until we have standard systems for communicating (both routing and common payloads for messages and notifications) and a way for applications to interoperate between systems controlling different parts of the workflow, then we’ll have ongoing issues with cross-organizational inefficiencies. See the MovieLabs Interoperability Paper for much more on how to enable cross-torganizational interop.

16. No common way to describe each studio’s archival policy for managing long term assets.

    Example: Storage service companies and MAM vendors need to customize their products to adapt to each different content owner’s respective policies and rules for how archival assets are selected and should be preserved.

    The selection of which assets need to be archived and the level of security robustness, access controls, and resilience are all determined by studio archivists depending on the type of asset. As we look to the future of archives we see a role for a common and agreed way of describing those policies so any software storage system, asset management or automation platform could read the policies and report compliance against them. Doing so will simplify the onboarding of new systems with confidence.

17. Challenges of measuring fixity across storage infrastructures.

    Example: Each studio runs a checksum against an asset before uploading it to long term storage. Even though storage services and systems run their own checks for fixity those checksums or other mechanisms are likely different than the studios’ and not exposed to end clients. So instead, the studio needs to run their own checks for digital degradation by occasionally pulling that file back out of storage and re-running the fixity check.

    As there’s no commonality between fixity systems used in major public clouds, private clouds, and storage systems, the burden of checking that a file is still bit-perfect falls on the customer to incur the time, cost, and inconvenience of pulling the file out of storage, rehashing it, and comparing to the original recorded hash. This process is an impediment to public cloud storage and the efficiencies it offers for the (very) long term storage it offers for archival assets.

18. Proprietary formats need to be archived for many essence and metadata file types.

    Example: A studio would like to maintain original camera files (OCF) in perpetuity as the original photography captured on set, but the camera file format is proprietary, and tools may not be available in 10, 20, or 100 years’ time. The studio needs to decide if it should store the assets anyway or transcode them to another format for the archive.

    The myriad of proprietary files and formats in our industry contain critical information for applications to preserve creative intent, history, or provenance, but that proprietary data becomes a problem if it is necessary to open the file in years or decades, perhaps after the software is not even available. We have a few current and emerging examples in some areas of public specifications and standards, and open source software that can enable perpetual access, but the industry has been slow to appreciate the legacy challenges in preserving access to this critical data in the archive.

In the final part of this blog series, we’ll address the gaps remaining within the Principles covering Security and Identity and Software-Defined Workflows… Stay Tuned…

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.

It’s mid-2023, we’re about 4 years into our odyssey towards “ProductionLandia” – an aspirational place where video creation workflows are interoperable, efficient, secure-by-nature and seamlessly extensible. It’s the destination. The 2030 Vision is our roadmap to get there. Each year at MovieLabs we check the industry’s progress towards this goal, adjusting focus areas, and generally providing navigation services to ensure we’re all going to arrive in port in ProductionLandia at the same time and with a suite of tools, services and vendors that work seamlessly together. As part of that process, we take a critical look at where we are collectively as an M&E ecosystem – and what work still needs to be done – we call this “Gap Analysis”.

Before we leap into the recent successes and the remaining gaps, let’s not bury the lead – while there has been tremendous progress, we have not yet achieved the 2030 Vision (that’s not negative, we have a lot of work to do and it’s a long process). So, despite some bold marketing claims from some industry players, there’s a lot more in the original 2030 Vision white paper than lifting and shifting some creative processes to the cloud, the occasional use of virtual machines for a task or a couple of applications seamlessly passing a workflow process between each other. The 2030 Vision describes a paradigm shift that starts with a secure cloud foundation, and also reinvents our workflows to be composable and more flexible, removing the inefficiencies of the past, and includes the change management that is necessary to give our creative colleagues the opportunity to try, practice and trust using these new technologies on their productions. The 2030 Vision requires an evolution in the industry’s approach to infrastructure, security, applications, services and collaboration and that was always going to be a big challenge. There’s still much to be done to achieve dynamic and interoperable software-defined workflows built with cloud-native applications and services that securely span multi-cloud infrastructures.

Status Check

But even though we are not there yet, we’re actually making amazing progress based on where we started (albeit with a global pandemic to give a kick of urgency to our journey!). So many major companies including cloud services companies, creative application tool companies, creative service vendors and other industry organizations have now backed the 2030 Vision; it is no longer just the strategy of the major Hollywood studios but has truly become the industry’s “Vision.” The momentum is truly behind the vision now, and it’s building – as is evident in the 2030 Showcase program that we launched in 2022 to highlight and share 10 great case studies where companies large and small are demonstrating Principles of the Vision that are delivering value today.

We’ve also seen the industry respond to our previous blogs on gaps including what was missing around remote desktops for creative applications, software-defined workflows  and cloud infrastructures. We can now see great progress with camera to cloud capture, automated VFX turnovers, final color pipelines now technically possible in the cloud, amazing progress on real-time rendering and iteration via virtual production, creative collaboration tools and more applications opening their APIs to enable new and unpredictable innovation.

Mind the Gaps

So, in this two-part Blog, let’s look at what’s still missing. Where should the industry now focus its attention to keep us moving and accelerate innovation and the collective benefits of a more efficient content creation ecosystem? We refer to these challenges as “gaps” between where we are today and where we need to be in “ProductionLandia.” When we succeed in delivering the 2030 Vision, we’ll have closed all of these gaps. As we analyze where we are in 2023 we see these gaps falling into the 3 key categories from the original vision (Cloud Foundations, Security and Identity, Software-Defined Workflows), plus 3 underlying ones that bind them altogether:

In this Part 1 of the Blog we’ll look at the gaps related to these areas. In Part 2 we’ll look at the gaps we view as most critical for achieving each of the principles of the vision, but let’s start with those binding challenges that link them all.

It’s worth noting that some gaps involve fundamental technologies (a solution doesn’t exist or a new standard, or open source project is required) some are implementation focused (e.g., technology exists but needs to be implemented/adopted by multiple companies across the industry to be effective – our cloud security model CSAP  is an example here where a solution is now ready to be implemented) and some are change management gaps (e.g., we have a viable solution that is implemented but we need training and support to effect the change). We’ve steered clear of gaps that are purely economic in nature as MovieLabs does not get involved in those areas. It’s probably also worth noting that some of these gaps and solutions are highly related, so we need to close some to support closing others.

Interoperability Gaps

1. Handoffs between tasks, teams and organizations still require large scale exports/imports of essence and metadata files, often via an intermediary format. Example: Generation of proxy video files for review/approval of specific editorial sequences. These handovers are often manual, introducing the potential for errors, omissions of key files, security vulnerabilities and delays. See note¹.
2. We still have too many custom point-to-point implementations rather than off-the-shelf integrations that can be simply configured and deployed with ease. Example: An Asset Management System currently requires many custom integrations throughout the workflow, which makes changing it out for an alternative a huge migration project. Customization of software solutions adds complexity and delay and makes interoperability considerably harder to create and maintain.
3. Lack of open, interoperable formats and data models. Example: Many applications create and manage their own sequence timeline for tracking edits and adjustments instead of rallying around open equivalents like OpenTimelineIO for interchange. For many use cases, closing this gap requires the development of new formats, data models, and their implementation.”.
4. Lack of standard interfaces for workflow control and automation. Example: A workflow management software cannot easily automate multiple tasks in a workflow by initiating applications or specific microservices and orchestrate their outputs to form an output for a new process. Although we have automation systems in some parts of the workflow the lack of standard interfaces again means that implementors frequently have to write custom connectors to get applications and processes to talk to each other.
5. Failure to maintain metadata and a lack of common metadata exchange across components of the larger workflow. Example: Passing camera and lens metadata from on-set to post-production systems for use in VFX workflows. Where no common metadata standards exist, or have not been implemented, systems rarely pass on data they do not need for their specific task as they have no obligation to do so, or don’t know which target system may need it. A more holistic system design however would enable non-adjacent systems to be able to find and retrieve metadata and essence from upstream processes and to expose data to downstream processes, even if they do not know what it may be needed for.

Operational Support

6. Our workflows, implementations and infrastructures are complex and typically cross between boundaries of any one organization, system or platform. Example: A studio shares both essence and metadata with external vendors to host on their own infrastructure tenants but also less structured elements such as work orders (definitions of tasks), context, permissions and privileges with their vendors. Therefore, there is a need for systems integrators and implementors to take the component pieces of a workflow and to design, configure, host, and extend them into complete ecosystems. These cloud-based and modern software components will be very familiar to IT systems integrators, but they need the skills and understanding in our media pipelines to know how to implement and monetize them in a way which will work in our industry. We therefore have a mismatch gap between those that understand cloud-based IT infrastructures and software, and those that understand the complex media assets and processes that need to operate on those infrastructures. There are few companies to chose from that have the correct mixture of skills to understand both cloud and software systems as well as media workflow systems, and we’ll need a lot more of them to support the industry wide migration.
7. We also need systems that match our current support models. Example: A major movie production can be simultaneously operating across multiple countries and time zones in various states of production and any down system can cause backlogs in the smooth operations. The media industry can work some unusual and long hours, at strange times of the day and across the world – demanding a support environment that can support it with specialists that understand the challenges of media workflows and not just open an IT ticket that will be resolved when the weekday support comes in at 9am on Monday. In the new 2030 world, these problems are compounded by the shared nature of the systems – so it may be hard for a studio or production to understand which vendor is responsible if (when) there are workflow problems – who do you call when applications and assets seamlessly span infrastructures? How do you diagnose problems?

Change Management

8. Too few creatives have tried and successfully deployed new ‘2030 workflows’ to be able to share and train others. Example: Parts of the workflow like Dailies have migrated successfully to the cloud, but we’re yet to see a major production running from ”camera to master” in the cloud – who will be the first to try it? Change Management comprises many steps before new processes are considered “just the way we do things.” There are many steps but the main ones we need to get through are:
   • Educating and socializing the various stakeholders about the benefits of the 2030 vision, for their specific areas of interest
   • Involving creatives early in the process of developing new 2030 workflows
   • Then demonstrating value of new 2030 workflows to creatives with tests, PoCs, limited trials and full productions
   • Measuring cost/time savings and documenting them
   • Sharing learnings with others across the industry to build confidence.

Shortly, we’ll add a Part II to this blog which will add to the list of gaps with those that are most applicable to each of the 10 Principles of the Vision. In the meantime, there’re eight gaps here which the industry can start thinking about, and do please let us know if you think you already have solutions to these challenges!

[1] The Ontology for Media Creation (OMC) can assist in common payloads for some of these files/systems.

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.