In vulnerability scanning, the entire infrastructure is checked with great regularity for errors and for other things which are not as they should be. The scanner goes through all the IP addresses within an IT infrastructure and investigates whether services are being offered and, if so, whether those services contain vulnerabilities. But… does that also work for infrastructure in the cloud? And if it does, how does it work?
Why vulnerability scanning
In a traditional hosting solution, you have your own infrastructure with your own network and your own physical servers. That means you manage your entire infrastructure and take care of configuration and maintenance yourself.
Does your company use a cloud service like AWS or Microsoft Azure? Read here what you need to bear in mind if you want to use vulnerability scanning to keep your cloud infrastructure secure.
Jos de Vos, Security Specialist bij Computest
Errors can already creep in when you need more capacity and you add and configure new servers. But also when using automated deployments, virtual machines can unexpectedly be created or, for example, not be properly 'cleaned up' after use. In addition, new vulnerabilities may be discovered which mean that a system that was secure yesterday no longer is today. In short, plenty of reasons to regularly scan the entire network and check that it is still in the correct, secure state.
Scanning your infrastructure when you have your own servers
Having your own infrastructure also makes scanning your own network a lot easier. After all, you have your own set of IP addresses which you can scan every day. To do so, you configure that IP range in a scanning tool like Marvin_. The scanning tool checks your network for vulnerabilities every night and in the morning it produces an up-to-date report with findings about any vulnerabilities.
Scanning IT infrastructure in the cloud
In the case of a cloud solution, rented virtual hardware is used. Not only servers, but also things like firewalls and routers are purchased through a cloud service like AWS, Microsoft Azure or the Google Cloud Platform. This is attractive for all sorts of reasons; the scalability in particular appeals to many companies. The option to be able to start with one small server and grow to dozens or even hundreds of machines is attractive, not least because the costs scale up evenly. However, there are some considerations to bear in mind, particularly in terms of security and infrastructure scanning. We list the 4 most important ones here.
4 considerations when scanning cloud infrastructure
1. Flexible, shared IT infrastructure
In a cloud solution, the infrastructure is not entirely in your own hands. Because you are using rented equipment, you are not only dealing with a third party like Amazon, Microsoft or Google, but also with any other users of the infrastructure.
Action point: Make a new selection of your own IP addresses to be scanned each time. The IP address assigned to one of your machines today may be in use by another tomorrow.
Because you generally hire individual machines, each one is assigned an arbitrary IP address. It is not the case that every customer of AWS, Microsoft Azure or Google Cloud Platform gets its own IP range. As a result, when scanning your infrastructure, you can no longer simply scan entire ranges. You need to make a careful selection to be sure you are only scanning your own IP addresses.
You'll have to redo this selection every time because an IP address that is assigned to one of your machines today may be in use by another tomorrow. Moreover, a scan like this can appear to the machine being scanned like a hacking attempt, so it pays to be careful when making and managing your selection.
2. Standard configurations
Most cloud providers offer one-click installations or templates. These templates allow a developer to immediately install a full application and make it go live without having to perform the installation themselves.
Action point: Check that there are no configuration errors in the default configurations that a cloud service provider makes available, and do not automatically assume that they are securely configured.
Doing so may save you a huge amount of time, but as a customer you cannot be sure that these default configurations are configured in the most secure way. Whereas you were assuming they were. So when hosting in the cloud, it is important to check that there are no configuration errors that could compromise the security of your network.
3. Overload
An infrastructure scan can sometimes cause extra load or noise on the hosting provider's network. You are sharing the processing capacity of the CPU and the network with other users.
Action point: Keep an eye on whether your cloud system automatically upscales itself in the event of additional system load when performing an infrastructure scan and if so, reset it so that you don't incur unnecessary costs.
Performing a scan can cause additional system load on the environment. This can negatively impact the experience of other users.
An infrastructure scan causes a substantial amount of data traffic. This can mean that cloud systems automatically upscale themselves and extra servers are deployed, incurring unnecessary costs.
4. Permission
Actively looking for vulnerabilities using an automated scanning tool is impossible to differentiate from attempts by attackers to discover the same vulnerabilities. For this reason, you need to consult the owner of the infrastructure beforehand about what you plan to do and ask their permission. After all, the infrastructure does not belong to you.
Action point: Tell the cloud hosting supplier in advance that you plan to use an infrastructure scan to keep your infrastructure secure.
In order to avoid causing unnecessary nuisance to other customers, a cloud hosting supplier will generally require that you ask permission before performing an infrastructure scan. This increases the barrier to performing an infrastructure scan.
How does Marvin_ tackle these challenges?
Because cloud environments regularly change IP addresses, we came up with a solution to this when developing the Marvin_ scanning tool. In the , you can specify a dynamic scope. That is to say that the end user can indicate very specifically, in an automated manner, which IP addresses are to be scanned and which are not. An API is available for this purpose, which means that a modified configuration or new machine is communicated to Marvin_ entirely automatically. This scope also has an 'expiry date': as soon as it elapses, it will no longer be used. This avoids old IP addresses being scanned which have since been assigned to a third party by the cloud platform. In this way, updating the scope of the scan can easily be integrated with automated deployment of cloud machines, for example from a CI/CD pipeline.
We configure Marvin_'s vulnerability scanner in great detail so as to avoid overloading the system being scanned. The scan also comes from a fixed IP address (or in any event a limited set of addresses) and runs within a set time slot. As a result, you can configure autoscaling mechanisms so that they are not triggered during the scan. What's more, with Marvin_, obtaining permission for a scan is not a stumbling block. Thanks to the extensive experience we have with scanning cloud-based infrastructures at Computest, we have excellent contacts with all the major cloud suppliers and we can get this sorted quickly.
- View the 8 most important Marvin_ features which guarantee that your IT infrastructure remains secure in the cloud.
