What the CoP - Is the Cloud forecast clear for TSA?
I often liken the process of achieving compliance with the Telecommunications Security Act (TSA) as being a journey, with many crossroads and pitfalls along the way. The devil is in the detail and there is a range of myths which can lead you into a cul-de-sac.
The use of public Cloud services is often a topic of conversation amongst my clients, mainly that they have heard that the use of public Cloud isn't allowed within the TSA. I always counter this with a comment that public Cloud services are not expressly prohibited within the TSA, but you do need to show how you are in control.
The relevant parts of the Code of Practice are Key Concept 6.7
It should also be noted that public telecoms providers are ultimately responsible for the security of their networks and cannot outsource this responsibility to third parties. Where providers do outsource aspects of operations to a third party, responsibility to comply with the obligations contained within new sections 105A-D of the Communications Act 2003, and the obligations set out in the regulations, remain with the provider. The provider therefore needs to have sufficient internal capacity to meet those obligations.
And also Technical Guidance Measure M2.06
The infrastructure used to support a provider’s network shall be the responsibility of the provider, or another entity that adheres to the regulations, measures and oversight as they apply to the provider (such as a third party supplier with whom the provider has a contractual relationship). Where the provider or other entity adhering to the regulations has responsibility, this responsibility shall include retaining oversight of the management of that infrastructure (including sight of management activities, personnel granted management access, and management processes).
A lot of people are reading the above as meaning that you need to show contractually that the Cloud Service Provider (CSP) can meet your TSA requirements, but what will come back will be an awful lot of assertion, a heady amount of not applicable and a range of imperfect responses.
So you need to work out how to satisfy yourself from the current compliance evidence which the CSPs provide, and where you need to mitigate the risks.
Recent revelations regarding the inability of Microsoft to guarantee UK sovereignty of policing data (https://www.computerweekly.com/news/366589152/Microsoft-admits-no-guarantee-of-sovereignty-for-UK-policing-data) have raised eyebrows, as have various recent significant outages within CSPs such as Microsoft, but does this mean that public Cloud is now becoming a no-go for the TSA?
What is Cloud?
In order to answer that question, we need first to determine what Cloud is as there is a huge level of Jargon-as-a-Service from vendors which serve to do nothing but confuse, especially in telcos where Open RAN (ORAN) is leading to Cloud RAN and Container-as-a Service (CaaS) terms which are not new service models for Cloud. Defining Cloud means that you can then compare existing virtualisation and private/hybrid Cloud service models on-premise with the public Cloud.
According to NIST, "Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."
What are the service models of Cloud?
Infrastructure as a Service (IaaS) – The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls)
Platform as a Service (PaaS) – the consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment
Software as a Service (SaaS) – the consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings
NIST, 2011
What are the challenges of using Cloud?
So with a clear definition of the standard terms relating to the service models of Cloud in general, it becomes easier to discuss what the key concerns are.
As a starting point, we can look at the Cloud Security shared responsibility model from the NCSC (https://www.ncsc.gov.uk/collection/cloud/understanding-cloud-services/cloud-security-shared-responsibility-model) - I've shown a version below which replaces the 'On-Premise' architecture with Monolithic (purely because in telco we are increasingly seeing the NIST service models deployed on private Clouds on-premise as well).
As we can see from the image above, there is a world of difference between a Software-as-a-Service (SaaS) delivery model compared to one which is provided on an Infrastructure-as-a-Service (IaaS) model. For clarity, most on-premise 'Telco Clouds' are a hybrid between IaaS and Platform-as-a-Service (PaaS), the latter being more prevalent where containers are utilised with the former being used for segmentation for containers.
The shared responsibility model means that you can start to understand where different responsibilities for assurance will lie across different departments or even organisations, dependant on whether the Cloud models are deployed in public Cloud or not.
On a private/hybrid Cloud deployment following the Cloud service models, the assurance will still need to be shown by those within the organisation's direct control (the virtualisation fabric being a key area of discussion, with activities specific to that shown below).
So far, so good, but how do you actually start to grapple with the assurance conundrum when looking at public Cloud and how far can you expect to get to move the dial from assertion (i.e. trust what we say) towards assurance (i.e. here's evidence of what we do) from CSPs?
In general, Cloud Service Providers (CSP) will:
NB - It's important to note here that none of the above are a criticism of the approaches taken by CSPs, Cloud services are usually provided as commodity services, and this requires commodity assurance approaches to deliver the pricing models.
None of these preclude the use of Cloud, but do require that we understand and manage the risks. These risks can be assessed both within public Cloud and on-premise variants (private/hybrid Cloud).
Risk areas to consider when assessing Cloud
In general, the following risk areas need to be understood when using Cloud services:
Once you understand the impacts of the data/services being proposed for placement within Cloud, then you can consider the risks for each area.
What are the risks to protection/trust?
What are the risks to access?
It should be noted here that neither Microsoft, Google, nor AWS recommend that their Cloud services are used for critical data (For an example, see 'High-Risk use' in the the Microsoft terms https://www.microsoft.com/licensing/terms/product/ForOnlineServices/all), although their well architected Cloud guidance provides a good overview of the things to consider in their guidance on critical workloads (example from Microsoft at https://learn.microsoft.com/en-us/azure/well-architected/mission-critical/mission-critical-overview ).
What this means in practice is that you cannot rely on the service being fully operational all the time and need to consider what controls you have to mitigate against the risk (e.g. you could have the minimum service level on-prem and expand out into Cloud with the HSM secured with your own keys).
How to manage risks in Cloud?
It's very difficult to assess what you don't understand, and as per Owen Sayers most recent analysis on the challenges organisations face in Public Cloud (https://www.computerweekly.com/opinion/Microsoft-outages-The-implications-of-downtime-on-the-delivery-of-critical-public-services) there appears to be a lack of critical thought prior to procuring public Cloud services.
In order to start the process, we need to first define:
How to define the information flows?
It's not enough to just move to Cloud, you need to understand the information you are placing within Cloud services and the how that data flows between different organisations and trust boundaries. The types of things we need to know are:
How to define the impacts?
Once you have understood the information flows, you need to know the impact in the event of:
How to define the use cases?
So you know have thought about the information proposed to be used within the Cloud services, but are you clear on how you intend on using the Cloud? These are questions you should be asking yourself:
How to define the obligation risks?
If you reflect on where you are at now, you've will have a come a long way to set out what you want to place into Cloud and how important it is to your organisation. But now you have to face up to the obligation risks to understand:
How to define nested supply chain risk?
As we have seen from Crowdstrike and multiple recent failures of CSPs (which again Sayers discusses at https://www.computerweekly.com/opinion/What-happens-when-the-it-infrastructure-IS-too-big-to-fail), it isn't enough to manage the risks you know about regarding your processing of data within public Cloud, but also key to ensure that you know what risk you are running from relying on outsourced services hosted in Cloud.
It's very rare unless white labelling another CSP's product for a SaaS product to truly opaque to the vendors, and most are running their SaaS on a PaaS (or more likely IaaS) instance in a public Cloud environment.
In order to manage this risk, are you able to confirm if you understand:
How does the CSP manage obligation risks?
Once you understand the flow, use cases and obligation risks, you are then in a place to reach out to the CSP to determine where they can help you in your need to present assurance of control. When speaking to the CSP regarding how much evidence then can provide to satisfy the identified obligation risks, you will likely get one of the following:
How do we manage gaps in assurance for CSP risks?
Just because you get a generic response doesn't mean that you cannot use the CSP. You first need to consider what mitigations you can implement within the Cloud service to address where you get either 'no evidence' or 'imperfect responses'?
In these areas, I recommend that you:
What's the best you can expect to get without detailed assurance?
As can be seen earlier in the article when we discuss the shared responsibility model, you can never expect to get any control (nor meaningful assurance) over network flow controls, host infrastructure and physical security within a public Cloud service even if you have IaaS. So what do you do?
In this case, the European Data Protection Board (EDPB - formerly the Article 29 Working Party) considered how personal data could be processed in various scenarios post the CJEU ruling on Schrems II in a report published in November 2020 (https://www.edpb.europa.eu/sites/default/files/consultation/edpb_recommendations_202001_supplementarymeasurestransferstools_en.pdf). Whilst this is within the EC legal space, it was published prior to Brexit and therefore likely to form part of the scope for review by courts and tribunals.
This report makes two things clear:
Therefore, it's obvious that the only way to provide an effective level of assurance will be to lock the CSPs out with robust encryption, This is, of course, something which is entirely possible by changing the keys within the Hardware Security Module.
Whether you need to do this depends on the risks that you assess in terms of using Cloud services. This, of course, is something that I see many organisations over-complicating the assessment process.
However, all this ensures is that you are not being subject to the confidentiality and integrity aspects of the CIA triad - not the availability one (as previously discussed).
Worked example for Public Cloud
If we take all of the above in consideration, let's look at the deployment of PaaS or IaaS in public Cloud as an example of what we could deliver:
Summary
Public Cloud has challenges, but they can be managed to align within the TSA compliance requirements. A challenge is where we expect specific assurance for the TSA to be derived from commodity-based assurance approaches within public Cloud services.
In order to more forward whilst keeping the public Cloud services within the risk envelope of the TSA, I recommend that you: