The Need for Observability around the Intrinsic Security Properties of Cloud not just what is in the Cloud
Knowing when the security of cloud falters has become critical in understanding true exposure.
The Challenge
As society increasingly relies on the cloud and its intrinsic security properties new risks have emerged around vendor behaviours with regard to security transparency. Specifically customer ability to understand where and when exposure exists in these platforms from fleeting vulnerabilities.
By way of example I could find one platform today which published security bulletins. For other cloud providers I looked at, be they IaaS, PaaS or SaaS, I couldn’t find equivalents. Nor is it clear how comprehensive these catalogues would be anyway i.e. in instances where the issues are internally discovered and resolved during a release cycle although they were present in production.
As we have embraced cloud vendors we have inherited agile software development practices and this has resulted in an asymmetric understanding in relation to the assurance of security at any point in time. Continuous integration and continuous delivery sees the pushing of releases for components often multiple times a day in some cases. Yet we don't have a the concept of security bulletins for more transient security issues in our industry as a general thing.
In these delivery models if an update introduces a vulnerability the potential exists for windows of exposure and increased risk to be measured in minutes or hours and not the days, months of years we might be used to.
What we seek is continuous assurance around the integrity and correct behaviour of intrinsic security boundaries in the first instance, for example:
Routable traffic filtering
Authentication
Authorisation
Intra-tenant access to APIs, virtual networks, data storage and similar.
Cross tenant access to services, APIs, virtual networks, data storage and similar.
In summary the security boundaries upon which we base our assumptions and who's behaviour if they changed would challenge these assumptions and pose increased material risk to us.
Enjoying this? Subscribe now:
Think someone else would benefit? Share:
A Solution
Given the challenge there appears to be value in the development of a comprehensive set of functional test cases for these foundational security properties by a third party.
These would be for each cloud provider be they IaaS, PaaS or SaaS with the goal of detecting and understanding the events where our assumptions don’t hold true and for how long they manifested.
This information would address the asymmetry in knowledge that fundamentally exists today.
We would in essence become omniscient to the real world whilst being able to gain assurance and understanding of:
What security functionally degraded
How
When
Where
For how long
The Eye of Sauron for Cloud if you will.
This new knowledge in turn would facilitate more focused deep-dive incident response to provide the assurance they were not exploited against specific environments.
Adversarial Advantage
When thinking about adversaries I’m always inspired by the talk from Rob Joyce in 2016 where he said:
“There’s a reason it’s called advanced persistent threats. Because we’ll poke and we’ll poke and we’ll wait and we’ll wait and we’ll wait, right? We’re looking for that opening and that opportunity to finish the mission.”
When we apply this to cloud you can see the adversarial advantage.
Shared Responsibility
Everything I have discussed to this point is the responsibility of the cloud providers. Beyond these we have the issues which are under the shared responsibility model in the cloud which was covered in this call to action in January 2022.
In short we have much to do…