This Github page is used to store all of the code and documentation related to Use Case 4 of the Horizon 2020 BEACON Project. The focus of this use case is Security. The aim of the work carried out is to provide an automatic security solution for newly created Virtual Machines (VMs) in the cloud. This security solution is split into two parts; evaluation and protection. This is achieved using several features which have been developed for this use case.
The three main aspects of this use case that are combined to deliver a security baseline are:
- OpenVAS Vulnerability Scanner
- Firewall Deployment
- Chef integration
These three main aspects of the use case are automatically orchestrated by a JAR file, comprised of the code found in the VulnerabilityScanner folder. This JAR file (known as the 'listener') 'listens' for incoming virtual machine details (UUID, IP Address, email address etc.) from the 'forwarder', a seperate JAR file comprised of the code found in the ForwarderExecutable folder. Virtual machine details are gathered by an 'activator script' running on the cloud platform, which detect the creation of a new VM. The activator script calls the forwarder with these VM details, which then sends them to the listener application.
The first step of the process is to conduct a vulnerability scan of the newly created virtual machine. This is performed using the listener application which interfaces directly with a deployment of the Open Vulnerability Assesssment System (OpenVAS). OpenVAS is an open-source framework comprised of several tools and services which provides a complete vulnerability scanning solution.
The listener application interfaces with OpenVAS to create and launch a new vulnerability scan on the target VM. This can be a surface level scan, or if the VM username/password is provided, a deeper scan of the filesystem can be conducted.
Upon the completion of a vulnerability scan, a report is generated by OpenVAS detailing the detected vulnerabilties. The listener application receives this report from the OpenVAS scanner, and sends this report to the email address supplied by the forwarder. This allows the VM owner to gain insight into the individual vulnerabilities that exist on the VM, as well as view an overall 'Severity' rating.
The next phase of providing a security baseline is the automatic deployment of a firewall to the VM on a cloud platform level. This is done automatically by the listener application using the API of the platform the VM is running on. The application supports the deployment of firewalls on the following cloud platforms: FCO, Openstack, Open Nebula and AWS.
Security groups on the host platform of the VM are the method used to apply firewalls to VMs. Security groups are defined as an identifier and a group of rules. These rules are built from several parameters, port, direction (inbound or outbound) and protocol. These groups are defined as firewall config files, which can be defined in order to provide customisable firewalls to VMs.
In order to specify which firewall config is applied to a VM, the application reads the VM metadata. The application scans the metadata looking for a 'firewall' attribute paired with a key specifying the particular firewall to be applied. This firewall value is then matched against the loaded firewall configurations. If no match is found, or no firewall attribute has been applied to the VM metadata, a default firewall is applied to the VM.
The final phase of the security framework that is applied is an automatic deployment of Chef on the VM. This feature is available subject to a username and password being supplied, as chef requires an SSH connection in order to be deployed. Chef is installed on the VM, and then a list of cookbooks are downloaded and applied to provide a final layer of protection on the VM.