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 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 – 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:
- Take a generic approach to compliance
- Provide generic service levels which benefit them
- Utilise global elastic computing
- Usually not allow customers to audit sites, or pen test remotely
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:
- Lack of protection of data/services (also called confidentiality)
- Insufficient trust in data/services through unauthorised changes (also called integrity)
- Inability to access data/services (also called availability)
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?
- The CSP can decrypt the Cloud instances (or data held within them without us knowing through poorly defined data protection boundaries
- The CSP can access the Cloud instances without us knowing through poorly defined credential boundaries
- The CSP can cause regulatory issues from hosting the Cloud instances without us knowing where data is stored through poorly defined residence constraints
What are the risks to access?
- The CSP can impact the availability of Cloud instances without us knowing through poorly defined service boundaries
- The CSP can prevent us moving the Cloud instances to other providers without us knowing through poorly defined portability of data/services (i.e. lock-in)
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), 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 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:
- The information flows
- The impacts
- The use cases
- The obligation risks
- Nested supply chain risk
- CSP obligation risk
- The mitigations of CSP risk
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:
- What is the data?
- Is the data being processed within Cloud?
- Is the data being stored within Cloud?
- Is the data being moved between service delivery boundaries (i.e. on-prem to off-prem)?
- Is the data being moved between trust domains?
- Are data flow directions understood (i.e. one-way, bidirectional)?
How to define the impacts?
Once you have understood the information flows, you need to know the impact in the event of:
- Lack of protection of the data (has it been compromised?)
- Loss of trust in the data (has it been modified?)
- Loss of access to the data (can we access the data within Cloud?)
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:
- Are key services being operated within Cloud?
- Are key controls being operated within Cloud?
- Are we data warehousing?
- Do we host commercially-sensitive services in Cloud?
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:
- What are the obligations related to the information flows and use cases?
- How do the obligations map to the CSP?
- How many of the obligations are reliant on the CSP?
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:
- Which key controls or asset types are hosted in public Cloud (e.g. for the TSA it would be your Security Critical Functions, Network Oversight Functions and vulnerability scanners)?
- Which key data is hosted in public Cloud (e.g. M365, Jira)?
- Which CSPs your key services are hosted on (e.g. Qualys, OSS)?
- Which CSPs your suppliers rely on for remote access (e.g. AWS for some vendors)?
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:
- No evidence
- Imperfect responses
- Self-assertion
- Verified evidence
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:
- Assess the threat vectors (how could the CSP impact data/services?)
- Implement control boundaries you have at your disposal (data protection, credential and/or service) to address the identified threat vectors
- Implement data encryption (ideally utilise ephemeral encryption in transit and at rest)
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. 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:
- Robust encryption must be implemented to be considered as an effective technical measure to control access in environments which have less trust due to concerns regarding law enforcement attempts to access data
- If data within the Cloud is able to be seen in the clear (e.g. the encryption mechanisms are capable of being access at will by CSP staff without the customers knowing) then any encryption deployed is not deemed to be an effective control
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:
- Implement control boundaries (data protection, credential and/or service) through control of encryption keys within the service, either through replacement of keys within existing service or the implementation of a layer of encryption within the service
- Implement ephemeral algorithms for data in transit and at rest to mitigate inference risk
- With the above – the risks remain for availability of service/data, but compliance now rests within the provider for operation
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:
- Identify the risks to the business from the use of Cloud (both public and private/hybrid)
- Identify where the responsibility lies (either between departments or the CSP and the organisation)
- In public Cloud deployments, identify what mitigations you need to implement when the CSP is unable to provide you with usable assurance
- Look to where you rely directly/indirectly on public Cloud services within your key controls, which CSPs are involved and the risk you are running