Service Oriented Vulnerability Management

Click here for a more concise summary of the Zero Vulnerability Framework and its execution framework, Service Oriented Vulnerability Management

In the prior article summarizing the key points of implementing a Zero Vulnerability Framework (ZVF), we mentioned the need to move to a service-based VM approach, which is the execution methodology needed to achieve a “Zero Vuln” environment. Here is a quick recap of what the ZVF is all about… and I should note that the ZVF is NOT about achieving the all-but-impossible state of having zero vulnerabilities:

1. Every vulnerability is accounted for, even if the overwhelming majority are “risk accepted.”

2. Risk Management is centered upon the attack surface (IT assets – hardware, network devices, software) and only in time-critical situations for vulnerabilities.

3. ITAM and related service management groups, which tend to fall under infrastructure and the CTO, should lead vulnerability management, with Cybersecurity governing and Digital Leadership & ideally, the board Championing.

4. Responsibility for remediation should be aligned with gradually improving processes or services, which will be the focus of this article.

To explain how to evolve from traditional risk-based vulnerability management to Service Oriented Vulnerability Management (SOVM), an explanation of three concepts:

1. The concept of remedial action and how remedial actions are the proper unit of work and consideration in Vulnerability Management (VM).

2. Why would we focus on IT assets when it’s supposed to be about vulnerabilities?

3. Vulnerability management is 4th dimensional – i.e., it is a continuous endeavor, and there is no “done.”

The Action

An “action” is the application of a “solution” via a “service” on an “IT asset”.

Some years ago, the idea of applying vendor updates was a cold-sweat-inducing affair.  Analysts and engineers would pore through the individual patches, methodically testing and pontificating into the wee hours to determine which should be applied. Today, it could be argued that un-bundling software updates presents far more operational risk to your business applications than simply using the latest complete set.

A single “action” on a single IT asset (in the above case, “Update [Software] to the latest fully patched version]”) can remediate hundreds and even thousands of vulnerabilities, depending on the scanning tool’s verbosity. However, there are several other important reasons to move towards actions and away from vulnerabilities.

• Most vulnerabilities are NOT risks requiring investigation and analysis but rather a published solution that needs to be applied. Except in emergency and zero-day situations, it’s hard for any non-cyber-related business to justify spending resources on “analyzing” vulnerabilities – that has already been done! Just apply the solution (via sensible change management practices, of course).

• Most solutions are repeatable and automatable. The vulnerabilities might look different, but the solutions are nearly always the same: Update, upgrade, reconfigure, remove software, or decommission hardware. Cases where non-standard solutions need to be applied (e.g., Log4J), are quite the exception. It has long been figured out that major operating systems release their security updates regularly, and using these solutions is always the same. There will be some testing, followed by an automated deployment, progressing through environments (e.g., development, QA, production, DR), followed by troubleshooting misses and cleanup. Set it and forget it.

• Following this point, representing remediation in actions enables you to progress toward refined remediation services. As you’ll read further, Services are essentially collections of remedial solutions (aka actions) for which the service is responsible for executing on a defined set of IT assets.

Managing By Attack Surface vs. Vulnerabilities

This logically follows from the prior paragraph. A single action can often resolve hundreds, if not thousands, of vulnerabilities. When many assets require the same actions, there is an excellent opportunity to gain efficiency through opportunistic collaboration, if not genuinely centralized services.

Another approach is to look at preventative or campaign-based initiatives. These typically target a particular software asset (such as Java or browsers) across many compute assets (cloud/virtual/physical servers and PCs).  As an anecdote – it is likely that within the 20 million Java-related vulnerabilities in the organization, there may be 1000 that are of “highest risk.” While you could spend all your resources expediting the remediation of those very few, that same effort could be used to execute a proper, infrastructure-led attempt to clean up images, audit installations, run removal campaigns, and institute a software lifecycle and patch management regimen/agreement for those that are required for the business.

The Continuous Nature of Vulnerabilities

No one said it better than Dr. Emmett Brown – “You’re not thinking 4th dimensionally!” Vulnerabilities are exploitable weaknesses in the code, status, or configuration of third-party software and their supporting infrastructure. Vendors will publish guidance and almost always deployable updates to remediate essential vulnerabilities. It’s not ucommon for these security updates to introduce new vulnerabilities that will then require subsequent updates inadvertently. The point is that vulnerabilities are NOT like cavities… You get them drilled and filled, and you’re protected for at least a few years. Vulnerabilities are like plaque; you must continue planning for the release and application of necessary updates regularly, just as you would brush your teeth daily. Hence, a Sisyphean Challenge will embroil VM approaches attempting to “reduce the mountain” by aiming at the highest risk vulnerabilities. The only way to win is to build services designed to expect ongoing updates and be prepared to address them expediently.

What is a Service?

A service executes “actions.” An example of a mature service might be procured from a service provider with clear SLAs and definitions.  For example, “Tech Service Company A” will have 98% of all US-based Windows PCs patched within 30 days of the vulnerability published date (i.e., “Patch Tuesday”).” An immature service example is, “All these vulnerabilities we don’t know what to do with, we assign to the business application owner to figure it out.” I will expand upon service maturity in a future article. Still, SoVM is evolving from sending vulnerabilities to often unprepared teams for accountability to aligning all non-risk accepted exposures to services that will execute remedial actions within an agreed timeframe.

There are four basic types of services: Preventative, Proactive, Reactive, and Passive.

Preventative

These are the services that work on reducing the attack surface and include services that enable other services in their remedial efforts. These areas are generally managed internally, or at least led, and often represent the most significant improvement opportunities. Some examples include:

• Technology Stack Governance – Any reduction to the basic technology stack applied to your compute assets is a win. Think of every piece of installed software as a magnet for vulnerabilities.

• IT Asset Management Data & Governance – To address vulnerabilities adequately, we need to know what we own, who owns it, what it’s doing, where it is, etc.… sometimes the most difficult challenge is *finding* an asset we know that we need to remediate

• Campaign-based services – These are campaigns to enable step-changes preventing future vulnerabilities, such as reducing a software footprint (e.g., browser consolidation) or enabling proactive patching (e.g., engaging application owners to work towards application stack rationalization)

Proactive

These services have processes to address remedial activities across many IT assets promptly. A refined (simplified) example would be a third-party negotiated service, and service items may look something like this:

Service: XBQ Computer Service Corporation Windows Server Silver Package

Scope: 500 Windows Servers, Frankfort KY Data Center

Service Items Included:

• Server Decommission Requests, SLA: 90 Days

• Windows OS Patch Tuesday Updates, SLA 30 Days

• Windows OS Configuration Changes, SLA: 60 Days

• MS Office, Chrome, Firefox, and Java updates applied within 45 days

• Any 3rd Party SW removal requests executed in 30 days

• Emergency updates applied within 14 days (extra negotiated cost applies)

Reactive

Reactive services might be considered more of a “management bucket” than a proper service. Still, for SOVM, we would consider these the most rudimentary of services, with an excellent opportunity to progress towards a proactive service or at least find improvements in efficiency and effectiveness.  A newer VM operation might discover much or even all their VM falling into reactive services, and it’s where everyone started in the beginning. A reactive service may look like this:

Service: Business Application Team Owned Actions

Scope: (Assigned from CMDB) Compute Assets Owned by Business Application Team

Service Items Included:

• Anything NOT Covered by XBQ Computer Service Corporation Windows Server Silver Package, SLA 90 Days

Passive (aka Risk Acceptance)

This is the primary service that Cybersecurity would administer. We will want to exclude swaths of vulnerabilities from consideration for a period or indefinitely because we’ve determined that pursuing them is not worth the cost. However, these exceptions should seldom be made at the vulnerability level but at the IT SW or HW asset level… i.e., at the attack surface level. Generally, the remedial solution involves updating a supporting piece of software, such as Java, or an application server. Given that new vulnerabilities continually come out for operating systems and the software stack, your exception must be updated every month or quarter.  As an example, if Java can’t be updated or removed because of legacy application functionality, then accept the risk or replaced the legacy application.

Future articles will expand into these areas and how TranSigma’s High Volume Orchestration (HiVO) Engine for VM can support the analytical side of a SOVM progression. The ZVF article also reviews the crucial stakeholder management aspects required to make these philosophical shifts, but at a high level, the benefits are compelling.

Why move towards Service Oriented Vulnerability Management?

•  Evolve from managing millions of vulnerabilities to a small collection of services

• Address vulnerability causes at their source rather than racing to apply solutions

• Establish stable, clear accountability that aligns with other organizations in the business

• Crush asset hygiene, leading to all the benefits infrastructure teams may have always wanted but never thought they could justify

• Ecosystem standardization

• Reducing SW bloat

• Reducing asset spend

• CMDB completeness and accuracy

• ITAM excellence

We’ve run and supported VM programs for over a decade, and because of VM’s rather unique position among the key stakeholder groups (cyber, infrastructure, application services, all risk stakeholders), investing in moving to SOVM can enable tremendous mutual wins throughout not only the digital organization but also the entire business.

A final note about “risk-based” Vulnerability Management

SOVM doesn’t replace risk-based VM but supercharges it by providing holistic visibility across the entire (known) vulnerability landscape. Even for emergency vulnerabilities, working towards better CMDBs, IT asset management, and maintenance processes will allow time-sensitive remediations to be applied in a far shorter timeframe. For more aged and standing vulnerabilities, you can use risk to determine the most critical services to invest in. That said, the first service to look at could be the “emergency remediation service,” which is essentially a risk-based VM with incredible speed. The improvement of this process will be strikingly evident as your organization progresses toward SoVM maturity.