5. The Shared Responsibility Security Model

Moving IT infrastructure to OpenStack creates a model of shared responsibility between the customer and the service provider. The amount of security configuration work that you have to perform will vary depending on which OpenStack services you select and the complexity of your infrastructure, but typically you are responsible for anything you put on the cloud or connect to the cloud. As an infrastructure provider OpenStack operates, manages and controls the components from the compute host operating system and virtualization layer down to the physical security of the facilities in which the service operates, but the layers above this consumed by the user will be their responsibility to manage.

Proper application of appropriate security groups to and security patching of VM infrastructure will be the responsibility of the users of the service, whereas maintenace of the physical infrastructure providing OpenStack service will be the responsiblity of the service operators.

Creation of appropriate security groups for virtual infrastructure that faces the CUDN or the global Internet is the responsiblity of the users owning and operating this infrastructure. For example, a web application server will likely not need to expose more than the bare minimum of ports to external networks than are needed to accomplish this function, and a sysadmin management server used to access internal OpenStack networks will also similarly perhaps only expose a limited set of services (such as SSH) and only then to a limited range of external networks (such as those belonging to the operating institution or group).

The UIS Friendly Probing service will scan all netblocks allocated to the OpenStack service at regular intervals, and users with virtual infrastructure exposed to the CUDN are expected to not take measures to block these scans, and allow the scans through Security Groups on CUDN-facing virtual infrastructure.

Where a security vulnerability is exposed by these scans, the owners of the virtual infrastructure will be notified by email and given the opportunity to fix the issues. If repeated scans confirm that the vulnerability is still present, or Cambridge CERT advice that a compromise has occurred or is very likely to occur, then virtual infrastructure may need to be remotely disabled by the service operators with warnings given by email.