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 participant1 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.
