Ultimate Guide to Running a Successful VM Campaign

In this article, a campaign refers to a time-bound project to significantly reduce a chosen area of VM—such as PC operating systems, browsers, middleware, ITAM data, and other security-related infrastructure concerns across the company-wide estate.  Campaigns are appropriate when there aren’t existing services in place to control a given set of vulnerabilities. The goal is to minimize the ongoing effort and end the campaign with a service put in place to manage those vulnerabilities.  Learn more about Service-Oriented Vulnerability Management (SOVM). The goals of a campaign, like any VM initiative, are as follows:

• Goal #1: Minimize the current attack surface

• Goal #2: Minimize the future attack surface

• Goal #3: Accept and monitor all risks where remediation comes at a greater business cost than the benefit of remediation

• Goal #4: Implement or improve the process of maintaining the remaining attack surface

Important stakeholders often hold various concerns about vulnerability management. The most common include:

• Concern #1: Inability to locate and/or assign ownership to assets 

• Concern #2: Fear of “breaking” a business application 

• Concern #3: Disruption of end users

• Concern #4: Lack of funding or resources 

For illustrative purposes, I’ll describe a campaign to minimize and control vulnerabilities related to Oracle Java.  According to the Qualys Vulnerability Signature Database, approximately 40 Severity 4 and 5 vulnerabilities are found annually in an unpatched installation of Oracle Java.

The Campaign Approach

Step 1a: Understand the attack surface:

As explained in greater detail in the Zero Vulnerability Framework, vulnerability risk and your attack surface increase in parallel. Every compute asset, every operating system, or, in this instance, every installation of Java makes up the attack surface. Lack of support, missing security patches, and poor configurations are what allow vulnerabilities to exist. Vulnerabilities are not things in and of themselves; they are deficiencies in your ITSM processes. Depending on the quality of your CMDB data, the campaign may begin with a data cleansing and enrichment exercise. This will address concern #1: identifying and assigning ownership to assets

Step 1b: Understand your audience:

                Yes… you may have to talk to a lot of people… or at least email them.  In the case of Java, the most important people are business application owners, who always understand their environmental requirements inside and out, wink wink.  For both server and endpoint installations, the requirement stems from the business application being used—developers and QA notwithstanding. 

                This is where we begin to address concerns #2 and #3. There’s a widely held misconception that campaigns are rolled out without any regard for the consequences… this should never be the case. The best campaigns achieve rapid results without breaking the bank or causing operational issues with business applications and user productivity.  Therefore, unless there is a true emergency, the first rule is Premium Non Secere—“First, do no harm”. 

Step 1c: Create a lightweight risk decision process:

                Remember our four goals for any VM initiative? Here is where we decide which outcomes help us accomplish those goals. In this scenario, we can eliminate some instances of Java completely (Goals #1 and #2). Where Java is necessary and cannot be patched or upgraded, we calculate the risk and decide whether we are willing to accept it (Goal #3). Where Java is necessary and can be patched or upgraded, we build a service to maintain the attack surface (Goal #4).  This step should start as a tracking exercise and steadily become more robust as the campaign progresses.

                Depending on the situation, it is reasonable to give 2, 3, or even 6 plus months for an application team to quantify the business cost of removing or updating installations of Java.  To start, anyone who claims they cannot update/upgrade or remove installations of Java must be believed, and their associated assets should not be touched until safety is confirmed, or a business decision is made.  Premio Non Secere! In other instances, it will be perfectly acceptable and reasonable to remove or patch instances of Java depending on the scenario. In this step, we build a framework to give ourselves the ability to make those decisions to appropriately address concern #4. 

Step 2: Pilot Remediation: 

Use management tools to determine when (if ever) Java is being invoked across the infrastructure estate to identify lower risk assets for the first pilots, and to see if Java needs to be part of the SOE (Standard Operating Environment). Generally, the requirement for deprecated Java will be confined to a handful of groups dependent upon antiquated—sometimes discontinued—business applications.  The safest groups will likely be in supporting functions like finance and IT, so look there first.  I won’t get into the details of communication plans, rollout schedules and the like in this article, but suffice it to say that no one should be surprised, and a very quick rollback installation process must be established. 

Identify and execute a small number of pilot groups, starting with low/never java users, and steadily progress towards users that are invoking java.  Depending on a user’s ability to install java (or allow the applications they use to invoke Java installation), monitoring these groups over a period of 30 to 60 days will provide very useful information. The results of these pilots should give a clear insight into how the risk/decision process (Step 1c) is operating and what changes need to be made.

Step 3: Accelerate the burn-down: 

This is where the heavy lifting is done.  For more sensitive assets, after a period where application owners have been allowed to investigate the impact of Java upgrades or removals—ideally testing on a development or sandbox environment – and the initial end user pilots are complete, there should be a much clearer understanding of where and how Java needs to be installed. Therefore, application owners can either elect to enter a more robust risk decisioning process or begin “long cycle” remediation.

• The Risk Decision process should now involve cyber and technology leadership, and demand some sort of “evidence” from the application team, such as confirmation from a software vendor, or ideally, the cost of enabling remediation.  

• Long Cycle remediation is a safe way to determine the impact of remediation on an application environment.  Simply put, application teams apply the remediation of their choice (either upgrading or removing Java) on their lowest environments, giving it an extended period, such as a month, to show any ill-effects, and then progressing up the environment chain in this manner until production and DR.  If there are issues, the application team can go back to the Risk Decision process.  If there are no issues, the application should enter “Short Cycle” remediation, whereby updates progress through the environment one week at a time. 

For endpoints, the process will be determined by pilot outcomes, but ultimately the goal is to: 

• Eliminate Java from SOE’s, unless there are known groups or users that need it. 

• Make users request Java if needed so that the installation can be tracked and is part of the regular update process. 

• Remove Java where possible. 

• Where not possible, update those users to a supported, patched version.

Step 4: Enable long-term control: 

At this point, you’ve achieved Goals 1 & 2 —the current and future attack surface has been minimized, and Java only exists where it needs to.  Goals 3 & 4 will be addressed by the risk decision process, and developing an ongoing service to ensure that all installations that ARE required are in a managed update process.  Discussions for establishing this can happen from Day 1, but the requirement is a service, delivered by internal or third-party teams, that ensures the safe but rapid application of Java security updates as they arise (typically quarterly).

This long-term control is ultimately what enables us to address concern #4. By having clean, well-owned, and well-defined processes and asset management, the practice of managing vulnerabilities becomes safer, more efficient, and cheaper.

Similar approach for everything: 

While Java is renowned for being one of the trickiest areas of Vulnerability Management, the campaign approach works for any unmanaged areas of VM.  Change management basics such as gaining leadership support and adjective communication will eliminate the issues of funding, engagement and collaboration.  A thoughtful, measured campaign approach should address any concerns around application or end user issues.