If you have ever dealt with security issues associated with a
datacenter or even a single server, you will know what vulnerability
scanning means. It is the tool used by both the “good” and “bad” guys.
“Good” guys use it to scan their network or server (in the case of a
small business running a single dedicated server) to make sure that
everything is up to date without any security holes. There are
different ways in which vulnerability assessment was done but some of
the widely used scanners were very intrusive while scanning. In fact,
some of the thorough scanning brought down the entire network or
server(s) completely leading to outages. However, businesses cannot
live without such scanning. It is the only way they could stay one step
ahead of the attackers. In fact, some of the e-commerce websites and
datacenters hosting financial information were required by PCI
compliance requirements that vulnerability scans are done periodically
to stay compliant. You might have seen this in the e-commerce sites in
the form of “Verified by xxxx” logos for security and privacy of data
in those sites.
In the traditional computing world, this was not a big problem.
Enterprises owned their own datacenters and small businesses had their
own dedicated servers. Any outage during the scanning processes only
affected the businesses concerned. In the world of Cloud Computing,
multi-tenancy is fast becoming the important keyword. In this new era
of shared resources, businesses are increasingly facing the dilemma of
not being able to do the scan. They can’t do the penetration testing to
make sure that their environment is secure. In fact, most of the Cloud
providers explicitly prohibit such a scan through their terms because
any scan employed by a business has the potential to disrupt the
services for other customers.
Even if we set aside the commonsense we gained from our Security 101
courses and not bother about these pre-emptive security measures, there
are regulatory requirements we have to meet. For example, PCI (Payment
Card Industry) compliance requires that we do vulnerability assessment
while dealing with financial data like the credit card processing.
These regulatory measures should be met for the very existence of the
business itself. If the Cloud provider ban such scans explicitly
through their terms, businesses are left with only option of not moving
to Clouds. In the end they lose out because they cannot leverage the
advantages of the Clouds.
The debate on how best to handle has been going around in the security
expert community and, also, amond the “Cloud pundits”. Recently, Craig
Balding of CloudSecurity.org wrote a post offering a suggestion to deal
with this problem. I thought I will talk about his suggestion here to create more awareness on the topic and, if possible, build on top of his ideas. His solution is a simple and straight forward one.
Assuming a cloud provider with a more measured approach towards
vulnerability scanning of customer cloud infrastructure, we now need a
simple, mutually trusted mechanism to agree scan sources, rate limits
etc. Something like an “ScanAuth” (Scan Authorize) API call
offered by cloud providers that a customer can call with parameters for
conveying source IP address(es) that will perform the scanning, and
optionally a subset of their Cloud hosted IP addresses, scan start time
and/or duration. This request would be signed by the customers
API secret/private key as per other privileged API calls. The provider
receiving the request can rely on the digital signature as proof that a
scan is authorised with the associated parameters. After the provider
has processed the scan authorisation request, the provider could return
a status code approving or denying the request (with a possible reason
code to allow resubmission with more acceptable parameters). This
response can optionally include rate limits which the customer can use
to tune the intensity of their scanner.The provider can now whitelist the customer provided scanner IP(s)
for the duration of the requested scanning window such that active
countermeasures like anti-DoS controls are not triggered, resulting in
a ‘cleaner’ scan (and hence a more accurate report).Should the scanning activity exceed any specified limits, or
communicate with IP addresses not associated with customer virtual
machines, the provider could instantly blacklist the scanning IP or
apply traffic shaping.
In my opinion, not having a solution is not an acceptable one. By enabling access to scanning using a ScanAuth API, Cloud vendors can keep a tab on the scanning process and make sure it doesn’t bring down their service completely. Probably, a good sets of standard guidelines on the parameters to be used for the scanning will help. Still, my knowledge of security is still rudimentary compared to Craig Balding, Christofer Hoff and others and I hope to hear more from these experts on this topic. If you have a take on Craig’s suggestion or if you have any other suggestion, feel free to jump in below in the comments section. As we have always told in this space, we encourage guest bloggers to discuss different topics related to Cloud Computing. If you want to write about Cloud Security and how we can deal with issues like this, send me a line.
