Co-authored in collaboration with Po T
The Government of Canada (GC) reached an important milestone with the launch of the GC Cloud Services Framework Agreement qualifying the first two providers, AWS and Azure, to host Protected B (PB)workloads.
Now that we have providers qualified, the question on everybody’s mind is “how and when can I access these providers?”. The Canadian Centre for Cyber Security, Shared Services Canada, and Treasury Board of Canada Secretariat have been working to describe that process. The result is the Operationalization Framework. Ooof, that’s a mouth full, isn’t it? I think we made up a word.
The goal of the Operationalization Framework is to implement a set of safeguards to protect GC cloud-based environments. This minimum set of guardrails will enable departments to maintain agility that is offered through cloud computing, but will also provide enterprise visibility.
Using the GC Cloud Services Framework Agreement alone does not make the environment ready to deploy PB data and systems. Through qualifying for the framework agreement, cloud providers services and operations have been security assessed. However, this is not a replacement for the departmental security and assessment activities. A department must still undertake those activities before deploying Protected B workloads into a production environment. The shared responsibility model is key in understanding why.
In the shared responsibility model, everything you, as the consumer, layers on top of the providers’ platforms must be secured by departments. In an Infrastructure-as-a-Service (IaaS) model, consumers inherit the security services and controls of the cloud, but are also responsible for the security of the platform configuration, applications, data, and user access/identity. This is one reason why if you must build your own applications, we continue to advocate for using Platform-as-a-Service before IaaS. PaaS is a simpler model.
The Operationalization Framework will ensure key guardrails are established in every department’s tenant. Those guardrails focus primarily on:
- Identity and access management
- Data protection
- Network and perimeter
- Logging and monitoring
These guardrails are the focus as they can be applied without any workloads present and ensure that the environment is ready for future enterprise services.
The framework’s minimum, mandatory guardrails can be found in the September 19th, 2019 attendee package for the Government of Canada Enterprise Architecture Review Board, but the process is as follows:
The guardrails originate from the Direction on the Secure Use of Commercial Cloud Services, which interprets existing GC security policy requirements in the context of cloud.
Again, the Operationalization Framework does not replace a security assessment and authority to operate. Implementation of these guardrails does not mean you can deploy PB data or systems to your cloud environment. (Are you tired of hearing that yet?)
The combination of the framework agreement, guardrails, the architecture found within the GC Accelerators, a department’s implementation of additional controls, processes, and policies will help your department achieve a secure foundation that is ready to host Protected B workloads.
Guardrails, not Gates
So why do we keep talking about guardrails? For some that may be a strange term to use. Traditionally, IT relies on process gating to police a user’s provisioning and configuration of a resource (compute, storage, network, etc…). Gates, however, often requires that the flow of work stops to allow for an external actor to arbitrate a decision point. This can lead to back logs as a queue of work waiting for arbitration accumulates. They are people intensive. Also, the arbitration can be based upon subjective criteria and lead to multiple interpretations of what is allowable and what is not. Gates interfere with the agility offered by cloud services.
This is why we prefer to implement guardrails. Guardrails keeps the flow of work within defined limits. These limits are typically enforceable through automation and monitoring. The boundaries can be quantitatively defined and applied equally across all flows of work. This is the perfect job for code. As long as the guardrails are respected work can continue uninterrupted. This allows the agility of cloud services to be maintained.
Another way of thinking of gates versus guardrails is thinking back to the era of traffic police standing in intersections directing traffic. This person intensive gating did not scale well as traffic volumes grew. Additionally, a police person’s job was focused on repetitive compliance enforcement. With time, the practice of having a traffic police person in every intersection was replaced with automation; the traffic light. The police person’s job evolved to active monitoring for those who did not respect the gates enforced by traffic lights. Taken further, red light cameras are a new level of automation. This is an example of how governance can shift from gating to guardrails to maintain scalability and allow flow to continue.
If your department is already using the existing public cloud services vehicle to build out a secure cloud-based environment that is aligned to the Government of Canada Security Control Profile for Cloud-based GC Services, then you’re probably in good shape to take the next steps towards using the new framework agreement. If you’re in a department with a legacy data centre closure on the horizon, you now have all the tools at your disposal to start migrating those workloads to cloud services. Policy, contracts, configurations,are all available. You as a department must build the skills and experience to use them with confidence.
Implementation of a trust, but verify model across the GC, like that Operationalization Framework, will enable departments to maintain agility, while enabling the central agencies to maintain visibility of GC information and assets that are now hosted in secure cloud service offerings.