Cloud Security INSIGHTS Archive: September 2020

The Evolution of Vulnerability Management on Cloud Endpoints

By Oscar Monge España, CISSP, CCSP

Image Credit: Getty Images

One of the most common challenges when securing the cloud is not having full visibility of all resources deployed. This exponentially increases the exposure factor, which could lead to a possible breach.

Six to eight years ago, when organizations started moving to the cloud, the main goal was a smooth transition in order to quickly reap the benefits of cloud to deploy workloads and reduce capital expenditures. Security came later.

Organizations tried to implement the same controls as on-premises, even the same vulnerability management technology. However, because of the cloud’s unique characteristics, the technology either was not cloud-oriented, or the information was not as reliable as the technology used traditionally to identify endpoints (IP address or hostname-based). In the cloud were other unique identifiers such as instanceID (AWS), UUID (Azure), Instance ID (Google) and instance-id (Alibaba).

A typical vulnerability management process runs on a recurrent basis within the organization; depending on the criticality of the systems, it can happen weekly, biweekly or even monthly. This would feed the first stage of the VM lifecycle: the vulnerability and configuration assessment.

Cloud endpoints’ lifespans could be totally different. One could spin a VM for a few minutes/hours/days and terminate it, although if the organization followed the traditional lift-and-shift it is most likely following the same rule of thumb as on-premises: a virtual system that lives forever in the cloud and gets patched on a regular basis.

Typically, on-prem vulnerability assessments involve a network vulnerability scanning solution. This approach we’re all familiar with. But cloud networks could be very dynamic and carry restrictions, such as cloud vendors that do not allow a network scan without prior approval.

Organizations started considering creative ways to tackle the vulnerability management problem. Some created hub-and-spoke connections between Virtual Private Clouds or virtual networks and would request permission from the cloud service provider to perform their security activities. Others sought industry-leading solutions providers to ease the security burden while allowing rapid adaptation of internal processes. This approach alleviated a common pain point: the lack of cloud security specialists on staff as the business defined its cloud vision and built out increasingly complex cloud infrastructures.

As with any other IT activity, there was—and still is—a cost associated with this level of outsourcing. For those that eventually decided they’d get a better return on their investments by building their own clouds, professionals were trained to create cloud-native infrastructure to fulfill the business needs.
Lately, we’ve seen how multiple cloud providers have either come out with their own vulnerability management solution or have partnered with strategic vendors to provide this service as part of their offerings. Such changes in the way vulnerability management is performed in the cloud means:

• More visibility is provided to the business unit and the organization
• Proactive measures can be taken and automated, instead of manually patching or assessing and patching on a regular basis
• A holistic view of information security–related issues can be gained, such as of security events and vulnerabilities

Because we’re talking about a multi-cloud strategy, the integration of vulnerability data might be a challenge. There could be a risk of vendor lock-in or differences in how data is consumed and correlated between endpoints. Enabling a cloud data lake might be a good option to centralize overall visibility and enabling the business to act upon collected data while feeding other sections of the vulnerability management process like enforcement, reporting and tracking of issues in an automated fashion.

How do we tackle these issues?

• Start by identifying which vulnerability management services exist per cloud service provider and the output provided; differences will exist depending on the vendor. Ask yourself: Can it be exported?
• Identify requirements to enable the capability on endpoints. Are agents or specific roles necessary?
• Define the vulnerability information destination bucket and format (if necessary, for consistency)
• Validate overarching vulnerability visibility against reporting endpoints
• Integrate with organizational processes to act upon data collected

Defining a solid vulnerability management strategy enables the organization to adapt its processes faster to disruptive technologies like containers, on which vulnerability management can be performed at the guest OS, container image and code deployed.

Vulnerability management is a ubiquitous process that will continue evolving. It is our job as information security professionals to ensure that processes and people evolve as nearly as fast as technology does, while enabling the organization to react in a more agile manner yet maintaining the security posture all along.

How can we do that? Understand that visibility is everything, and the same technology might not be suitable for all use cases. Think beyond vulnerability management and be vigilant about costs and budgets. Finally, never forget that any technology, any vulnerability management system will fail if you disregard your people and processes.

Oscar Monge España, CISSP, CCSP, is a security solutions architect for Rabobank with a passion for information security and technology alignment to IT business needs.

---

View INSIGHTS Archive >>