Imagine a scenario where you are tasked to audit the security of an organization’s efforts to “cloud-source” applications, operating systems, databases and other aspects of IT infrastructure. You want to fire up your favorite network scanner, Nessus, but are warned that some of the outsourced companies have clauses that prevent auditing, network scanning or security testing. Even still – some of the technology is at the API or SQL level and there isn’t even an identifiable OS to scan. Last, even though you may be able to perform a scan quickly, some of the cloud resources get charged at an hourly rate and the act of auditing costs your company money that the application group did not budget for. Fortunately, passive vulnerability scanning can help audit remote resources that are now off your network and “in the cloud”.
How does this work?
If network traffic to the remote cloud occurs over common TCP/UDP protocols such as HTTP, SQL or SSH, Tenable’s Passive Vulnerability Scanner (PVS) can be used to monitor the communications, perform protocol analysis and identify the applications and vulnerabilities used by the remote “cloud” organization. As your employees and customers communicate with the resources in the “cloud”, the network traffic can be used to identify what technologies are in use.
Depending on your “cloud” application or technology, you may find issues at the API, OS or application level. For example, consider a service that offers access to a MySQL instance. Your applications can make SQL queries directly to your MySQL instance “in the cloud”. In this case, passive monitoring would watch the SQL queries to determine the version of SQL as well as any vulnerabilities associated with it. On the other hand, if your remote solution was a full virtual operating system, you may observe client-side vulnerabilities in web APIs, web browsers and other end-user software if they communicate back to your organization.
What can you do when you find a vulnerability?
If you think this question was the next logical question – you are ahead of the pack. Most executives I speak with feel that once they outsource to the “cloud”, security is no longer their problem. I could not disagree more. However, for those that monitor the enterprise, what are your options when you do find a vulnerability in your “cloud” vendor? Fortunately, there are several options:
Compensate
If you know about a given vulnerability, you can take actions to mitigate it. Maybe you can effectively apply some sort of patch to your system. Maybe you can use a different technology that is compatible and not (currently) vulnerable. At a minimum, if you understand the vulnerability and how it can be exploited, you could leave it in place, and watch for signs of exploitation.
Complain
Even if your service level agreement with your cloud vendor does not cover security patches or upgrades, opening up a trouble ticket can work wonders. This action may force your vendor to at least acknowledge the issue and provide guidance if they will or will not fix it.
Get a New Cloud
It may be possible to find a new vendor that does not have this technology flaw, has a better record at network security or responds to security concerns more promptly. Switching “cloud” vendors can be just as painful as the first move of applications and data off your own network.
