The Trusted Computing Base (TCB) is one well known way to assess the security vulnerability surface area of a given system. TCB is basically the sum of the securable surface area of a system including its software, hardware, firmware, and networking components. The likelihood of a vulnerability (bug, attack, etc.) in a system increases as its TCB increases. The more pieces that make up a computing system, the more complicated it becomes to identify and subsequently protect its trusted computing base. One cannot adequately secure and operate a system without first knowing its TCB.
For the purpose of example, I’m going to use three different approaches to private cloud environments we see in use by organizations today.
- IaaS (datacenter)
- PaaS atop virtualization (datacenter)
- PaaS atop bare metal (datacenter)
Infrastructure as a Service
Even in private datacenters, IaaS – on demand hosted virtual resources – is typically implemented as operating system templates within virtual machine templates atop provisioning automation atop physical hardware resources surrounded by networking. Clearly, this is a bit of a trivialization (I’m not going to get into things like block storage, etc,). On top of that stack is where application workloads go to be consumed by end users. This alone represents a pretty complex and deep trusted computing base with a lot of interconnected parts to cover – more moving parts equals more surface area with possible vulnerabilities.
Additionally, most IaaS platforms are multi-tenant, meaning that without proper isolation, the trusted computing base of one tenant actually has to incorporate those in use by other tenants. Consider the scenario of a bug or other anomaly existing on a dormant VM image, only to spin up on request by one consumer and propagate through one of the IaaS, OS, or hardware layers into other running virtual machines. Not a good scenario, and definitely something that has to be factored into a policy to protect the entire trusted computing base.
PaaS + Virtualization
Organizations that haven’t adopted self-service automation for VM deployment may still have incorporated virtualization into their datacenter. In this approach, the VM stack is statically provisioned per change request and application workloads consume finite resources until a manual, or IT-performed, expansion is completed. Nonetheless, the trusted computing base is still deep, and the stack still includes a layer that introduces cross-workload TCB concerns: the hypervisor. In this scenario, there is significant effort in implementing controls around each level of the stack with particular attention paid to protecting the hypervisor from broad vulnerabilities. In fact, entire products might be introduced to “prevent catastrophic cloud failure,” as it is described by Hytrust, a company that sells one such product.
PaaS + Bare Metal
Platforms like Apprenda introduce a different way to look at TCB, especially when implemented on “bare metal” infrastructure – server and networking hardware alone. This implementation approach most closely resembles the traditional datacenter, which means migration to this model is less disruptive, expansion of TCB is minimized, and traditional approaches to addressing TCB concerns are still relevant. Monitoring, detection, and analysis tools that are currently used in the datacenter maintain their effectiveness.
The PaaS is applied up stack, which means no uprooting of the OS layer and no cross-cutting TCB concerns introduced by virtualization. Of course, the PaaS should be added to TCB assessment, but this exercise is far less impactful by running PaaS atop existing infrastructure and OS instances (which of course pays dividends in bypassing IT red tape during implementation as well). We see a steady rate of our enterprise customers implementing Apprenda atop bare metal for these reasons.