System isolation or cloud migration? Weighing the risks and benefits
One of the key conundrums faced by IT system managers is whether to isolate their systems or migrate their infrastructure to the cloud. To help you make an informed decision, let’s examine the challenges of system isolation, the risks of interconnections, and how cloud migration can resolve or accentuate this issue.
The limitations of system isolation
One of the classic techniques to protect a resource is to hide it as deeply as possible and, if applicable, isolate it from the rest of the world. In this way, we can make its external attack surface disappear by eliminating interconnections with the outside world.
However, a system can never be 100% isolated and it would be a mistake to believe that isolated systems are free from risk. There are countless attacks on isolated systems via corruption techniques or supply chain attacks as depicted below:
Fig. 1: Supply chain attacks
Nevertheless, this logic has been proven to work and it continues to do so. However, it poses a challenge to the current digital transformation trend driven by the increasing interconnection of systems, including the most sensitive ones. Virtually no industry is resisting this trend.
Consider these examples:
Processing the most critical monetary and financial flows requires an enrichment by external elements which necessitates a close collaboration between different actors for faster transactions — such as fraud control, compensation and tax optimization.
The performance of industrial equipment is subject to the interconnection of these systems with external entities to ensure proactive, and sometimes even predictive maintenance.
Even some weapon systems have part of their components connected and exposed in controlled networks to enable technical and security supervision.
The COVID-19 pandemic accelerated these dynamics and forced some systems managers to make exceptions and open their systems to allow access for users with specific and very rare skills not available locally.
But as we know in security, anything that has been opened is practically impossible to close again.
Controlling the risks of interconnections
Generally, isolated systems are not designed to be exposed or interconnected.
The process of opening up, either voluntarily or involuntarily, requires a thorough review of the system architecture. Some see this as an opportunity to migrate these systems to the cloud.
In the case of a controlled opening of a system, the following applicable risks should be reviewed:
Intrusion via the exploitation of a vulnerability in the exposed functions (such as a weak protocol, an API, a shared technical brick, etc.)
Malicious use of exposed functions to disrupt the underlying system by bypassing access controls or introducing malicious loads
Overloading exposed interfaces
Fig. 2: Types of applicable risks in a controlled opening
There are several classic and effective technical measures that can be used to reduce these risks:
1
Technical and network mapping (with a detailed inventory of flows)
2
Interface protection for access control and protocol break
3
Decontamination of incoming flows
4
Network inspection and blocking probe (IDS/IPS)
This openness challenge is technically achievable if the system architecture redesign is sufficiently deep. The additional risks are not as numerous, with a few additional tactics, techniques and procedures (TTPs) to consider according to the MITRE ATT&CK framework.
With their eyes set on expected benefits that outweigh the remaining technical risks, many enterprises have already taken this step.
Cloud: The ultimate node of interconnections
Some organizational system managers opt to accelerate the digital transformation of their systems and migrate them to the cloud, even if it means changing the entire architecture of their isolated systems.
Is it possible to make this change and still control the risks? Yes!
Is it contrary to the regulations in some countries? Yes, sometimes.
Aside from regulated systems where the law prohibits migration to the cloud, a strategic and effective approach is to study the security measures to be deployed to enable the use of this type of execution base.
This list of measures obviously includes the previous guidance concerning the control of interconnections. It is completed by specific measures linked to the isolation of sensitive activities from those of the service provider, which becomes a vector of risks – that is difficult to transfer contractually.
Fig 3: Risks of isolated systems in the cloud
Examples of these measures include:
Outsourcing key management via bring your own key (BYOK) and hold your own key (HYOK) mechanisms as offered by Google’s s EKM Cloud service and AWS’s XKS service
Using trusted execution environment enclaves such as Microsoft’s Azure Confidential Compute
Using trusted execution environment enclaves such as Microsoft’s Azure Confidential Compute, AWS’s Nitro Enclave and Google’s Asylo
In addition to changes in the distribution of risk drivers, we must not overlook the fact that the tools and processes for operating security in these environments are very different from traditional approaches. There is a real need to rethink the skills of the architect teams and administrators and acquire tools capable of dealing with both exposure issues, such as Cloud Security Posture Management (CSPM) and internal security issues like cloud workload protection platforms (CWPP).
Weighing risks and opportunities
The transformation of a critical and isolated system to the cloud can present several major strategic interests as long as the movement does not oppose the applicable regulatory framework.
While it is not necessary to highlight the advantages of cloud services, we will reiterate the following:
The security models used by cloud service providers are highly segmented and allow them to effectively combat individual corruptions.
The underlying infrastructures of cloud service providers are more opaque and hybrid. Attackers may find that the reconnaissance phases are now less straightforward than they once were.
Infrastructure and system updates are automatic and much more frequent than can be achieved in an isolated system.
The resources committed to ensuring the security supervision of cloud provider systems are greater than you can implement on your system alone.
Taking the plunge
Keeping in mind that isolating a system does not eliminate the risks of compromise, we believe that the progressive and controlled exposure of a system is not incompatible with its degree of criticality, even to the point where it can be supported by a cloud offering. However, this exposure requires a profound rethinking of the system architecture and the implementation of adequate security measures adapted to this new medium.
As concepts, tools and skills evolve, my advice to organizations is to take the time to explore this transformation today, rather than to undergo it as an emergency tomorrow.
Share this article
About the author
Jean-Baptiste VORON
CTO Cybersecurity France
For the last ten years, Jean-Baptiste Voron has been working with the Chief Information Security Officers of major French groups on new cybersecurity issues.
With Atos since 2012 as an expert consultant in IT security governance and strategy, he is now responsible for the portfolio of cybersecurity offerings in France. In this role, he leads the team in charge of cybersecurity presales to cover a range of more than fifty technologies and partners.
He frequently works with Atos’s strategic clients internationally in the design and deployment of cybersecurity solutions.
Jean-Baptiste holds a PhD in IT security (joint US/French thesis) and a master’s degree in complex systems and applications from Pierre & Marie Curie University.
Follow or contact Jean-Baptiste
