To Agent or Not to Agent: That Is the Vulnerability Management Question

Image

With the evolution of technology comes new approaches to solving problems. Sometimes a new approach fixes the problem; sometimes it creates new ones. The good thing is as folks who work in fast-paced, high-tech environment, we information security professionals are great at quickly analyzing the new technologies and applying them to our daily lives. ...Or so we thought! Every once in a while, we need someone to take a complex debate and simplify it down for us. This blog post will look at how the age-old agent vs agentless debate has dawned a new approach to assessing vulnerability risk on various types of assets including on-premise infrastructure, cloud infrastructure and containers. First, let us examine the various ways to assess vulnerability risk and then look at which scenario best applies to different types of assets. There are four basic approaches that one can take when determining the risk of an asset: (1) the outside only approach; (2) the outside-in approach; (3) the inside only approach; and (4) the inside-out approach. To explain each of these types of approaches, imagine purchasing a house. There are different approaches one can take to examine this house. We will look at each of the four approaches as if we were examining said house. We will then follow up by applying each approach to vulnerability risk assessments.

The Outside Only

This is the traditional way of examining a house. In this approach, you literally walk up to the house and start looking at the outside of the house. You carefully examine the walls, grab a ladder and examine the roof and take a look at the windows. Once you identify how many windows there are and the size of them, you can take a look inside each one to see how much of the inside of the house is visible and if any of the windows were left open. This approach is similar to that of an unauthenticated vulnerability scan. In this approach to vulnerability scanning, a network scan is run to identify what hosts are alive, the open ports and services along with what vulnerabilities can be identified based on those identified ports and services. Typically, this is how an attacker would be able to scan the environment. Depending on the vulnerability scanner in use at your organization, this process can sometimes have a heavy impact on the network. It is best to use a scanner that limits the amount of data sent across the network to only that which is required based on the identified operating system, ports and services.

The Outside-In

Now that you have seen the outside of the house, the next thing to do is to take a look at the inside. Since you are buying a house, you made an appointment with a real estate professional and gained their authorization to view the inside of the house. Using that authorization code or key, you walk through the front door to conduct your examination of the inside. There may have been things you were able to see through the windows, but being on the inside allows one to get a deeper understanding of the various intricacies of the house. This approach is similar to traditional on-premise vulnerability scanning. The vulnerability scanner uses a credential and/or certificate which someone either inputted into the configuration of the vulnerability scanner or checked out from a password vault. This type of scan will give the organization an image of the true risk of each asset as well as identify vulnerabilities that can be exploited by attacks such as a malicious PDFs or other drive-by downloads.

The Inside Only

For the purposes of this section, you have already bought the house and are living in it! Imagine yourself waking up one morning and deciding that this is the day you want to examine every nook and cranny of the house. This could be something you schedule on a periodic basis or decide to do it ad-hoc. Similar to a credential-based scan, you are already on the inside of the house, so you can carefully examine the interior of the house. Since you are already inside, however, you do not need a key or code to enter. This approach is similar to agent-based vulnerability management. Using this approach, an agent is deployed on each asset that requires the vulnerability risk assessment. Agents are deployed primarily on servers and workstations or laptops. Devices such as network gear and appliances typically cannot have an agent deployed.

The Inside-Out

Continuing with the example of already having purchased the house and thoroughly examined the inside of it, the last thing to examine is the roof and the walls. It is still important to periodically verify that there aren’t any leaks or open windows. You can still ensure that the doors and windows are locked from the inside, but to actually see the outer walls and the roof, you have to go outside. This approach is similar to running an authenticated scan with an agent on the system. The primary source of data is the agent, but the last little bit of assessing the external risks comes from the scan.

Agent or Credentialed Scan - Which Approach Should I Use?

There is a lot of debate as to whether one should deploy an agent or run a credentialed scan. The beauty of having a single vulnerability management solution that can do both is that the organization is not limited to a single approach. Whether one were to use the Inside-Out or Outside-In approach to assessing risk, the solution is capable of providing an accurate picture of the risk of the asset. The challenge comes if the organization is limited to an Outside-Only view or an Inside-Only view. With the Outside-Only view, the scope of assessment is limited to only that which is visible externally. While one can see what an external attacker would see, it does not give a true representation of the overall risk of the asset. With the Inside-Only view, the vast majority of risk is assessable, but there will always be a small view that can only be seen from the outside. The approach may change depending on the type of asset one is examining. Here are some things to consider when determining whether to use credentials or agents for on-premise infrastructure:

• For some organizations, credential management is challenging; therefore, an agent would work best. Meanwhile, other organizations experience agent fatigue and would prefer to use a credential-based scan.
• There are some systems that need a more real-time analysis; therefore, having an agent makes more sense, whereas there are some types of assets that are not as critical and can be analyzed on a less frequent basis.
• Transient assets, such as laptops, are not always connected to the corporate network and could potentially miss the scanning window. Therefore, having a vulnerability agent deployed allows the risk to be assessed while the laptop is on and the data downloaded as soon as there is a connection back to the corporate network.

https://www.slideshare.net/Tripwire/vulnerability-management-myths-misconceptions-and-mitigating-risk-part-i

Vulnerability Management in the Cloud

Infrastructure in the cloud gets a little more complicated. There are two main ways to approach assessing the vulnerability risk for cloud assets. The first approach is a modern take on traditional vulnerability assessments. An agent can be deployed on each virtual image just as it would for an on-premise asset. The difference for the cloud infrastructure would be that as soon as the image is spun up, it self-registers with the vulnerability management console and assesses itself. If it meets the vulnerability risk threshold, it should be allowed to continue. If not, it should be stopped. Furthermore, if that image is persistent, it should be reassessed either when a change is detected or on a regular basis. The second approach is to shift further left into the CI/CD pipeline. In this approach, a security gate is inserted into the development lifecycle so that as soon as a developer is done building an image, it can be tested for vulnerability and compliance. This allows the security team to set a passing threshold for the acceptable risk of the image. If the image as constructed does not meet acceptable levels, the image gets sent back to the developer along with the remediation instructions required to attain a passing grade. Ensuring that both these approaches are workable in your organization allows the organization to verify that only images with appropriate levels of risk are deployed and the security team to maintain visibility into the risk of the images throughout their life cycle. An added bonus is to have a solution that can kick off an action when certain criteria are met. For example, if an image in production exceeds its acceptable risk threshold, a workflow can be automatically triggered to instantiate a new, updated image to replace it. As someone who has been working on vulnerability management for over 10 years, the evolution of technology never ceases to amaze me. While technologies change, the foundational principles of security remain the same, however. If a thief finds a way to steal something, they will steal it. As security professionals, we need to ensure that we are able to support our business partners in their efforts to effectively mitigate the risk of their activities in a way that least disrupts their operations. The ideal scenario is to have security built into the business processes so that they don’t even know we’re there!