The Siphonaptera has various versions. The version I learned as a kid goes:
Big bugs have little bugs,
Upon their backs to bite 'em,
And little bugs have lesser bugs,
and so, ad infinitum.
We make use of this fact a lot in computer security; a breach of the OS can impact the security of the application.
We could even build a simple dependency list:
The security of the application depends on
The security of the operating system depends on
The security of the hypervisor depends on
The security of the virtualisation environment depends on
The security of the automation tool...
Of course, in reality the dependency list is a highly branching tree; the app may depend on multiple different things in order to be secure, such as the source code repository, the build environment, the single signon solution…
This seems obvious; if I can break into the central management tool then I can use that to break into VMs and from there impact the app.
Bidirectional
We also have some awareness that the list isn’t one way. We know about remote code execution and privileged escalation attacks, so we can also say:
The security of the operating system depends on
The security of the application
A problem comes in when we have a large difference in organisational security boundaries. A broken app allowing privileged access to the OS is annoying, but it’s still (normally) only the app that’s directly impacted.
However when there’s a higher level structures in place then we may have multiple applications impacted; a hypervisor bug may allow an application in one OS to impact a different application in a different OS.
It gets even worse; a bug in the hypervisor management layer (e.g. the VMware agents feeding into VSphere or VCOps) could cause a bug in an application leading to impact every server in the enterprise.
We saw a variation of this, recently. An ansible bug allowed a
compromised machine to run commands on the controller node. And,
of course, the controller typically has access to every machine managed
by ansible, including root access on those machines.
The security of the application depends on
The security of the operating system depends on
The security of the hypervisor depends on
The security of the automation depends on
The security of the hypervisor depends on
The security of the operating system depends on
The security of the application
With all the branches!
Assessments
When we do application risk assessments we tend to focus on the app and the OS that runs it. We don’t look at the automation environment, the authentication tool, the hypervisor management because these are “the same” across app deployments in an enterprise, so not worth testing hundreds of times over.
This can lead to a gap; we need to ensure these tools are properly covered and managed. If you pay for an external team to pen-test your app then it may be a good thing to resist the temptation to limit their scope; let them try and break the higher level constructs that your app depends on. You might learn something new; something a real attacker could use against you!
At the very least ensure your tooling is fully patched and that bugs found against them are evaluated as having company wide impact.