When it comes to security, multiple aspects need to be reviewed. Although it is very important to remember the security requirements of CSPs, the significant aspect to consider are those that can be affected by the virtualization of the network functions.
When CSPs do not use virtualization, every electronic component has a dedicated purpose, sometimes with specific implementations in silicon (ASICs) or dedicated execution environments for software running on x86 (bare metal computing).
When virtualizing network functions, we are not leveraging physical barriers therefore the principle of security by isolation does not apply anymore. In the worst case scenario, we can have the same CPU executing instructions for two VMs simultaneously: one participating in a DMZ (De-militarized zone) and another running a HLR (Home Location Registry) with customer records.
In NFV, the hypervisor provides the separation between VM contexts. It is the job of the operating system to provide policies like SELinux and sVirt to ensure that the VMs behave properly. Then, it’s up to the scheduling system (Openstack) to guarantee host isolation via Anti-Affinity rules and other policies. Those policies monitor not just the entry points (input-output) but also the operations VMs are allowed to perform, in terms of memory access and device management. When the Service Provider needs more global policies and automated enforcement and auditing, Red Hat recommends Cloudforms or Satellite as additional management layer.
The security concerns are so critical that customers demand to see the hypervisor source code as the ultimate measure to audit the quality of that isolation. Thanks to the work of Intel with other open source communities, KVM now uses the latest CPU technologies, including built-in security enhancements.
Some of the features that protects Linux and KVM include:
- Process Isolation, supported by CPU hardware extensions
- MAC isolation by default (SELinux and sVirt)
- RBAC and Audit trail
- Resource control (CGroups)
- FIPS 140-2 validated cryptographic modules
- Disk encryption (LUKS) for data at rest
- Strong key support for SSH (AES256) for data in motion
- PKI authentication for operator management, SSL when using the HTTPS interface
- SCAP audits supported (OpenSCAP), using the Security Guide developed with NSA, NIST and DISA
Detailed documentation of the security mechanisms of Linux and KVM can be found here.
Leveraging the decades of work to make Linux suitable to the demands of an enterprise environment has created a vast ecosystem of tools, including default policies like PolicyKit and SELinux and auditing tools like OpenSCAP. This is the reason why you can find Linux and KVM on mission-critical systems like healthcare, government, finance companies and even the military.