Last updated at Tue, 16 Jan 2024 16:30:59 GMT

Overview

An unique feature of the Nexpose vulnerability management (VM) solution is that the core of the underlying scanner uses an expert system.  Many years and several careers ago, I had been tasked with selecting an appropriate VM solution at my employer.  Among the possible solutions was Nexpose, and I am somewhat embarrassed to admit that I shrugged off the "expert system" as a marketing term.  I soon came to learn that it was a real thing and started to realize the true power of such a technology.  Fast forward to present day and I've been immersed in Nexpose's expert system for nearly four years.  In utilizing Nexpose, one may find it helpful to understand what an expert system is, how Nexpose specifically uses an expert system, and finally the benefits of an expert system in VM.  This blog post aims to address those points.

What is an Expert System?

If you were to define an expert system by combining the definitions of expert and system you would be pretty much spot on.  It is quite accurate to say that an expert system is a set of components that interact with one another to obtain a high level of knowledge about a particular subject.  The goal of an expert system in AI is to utilize computer systems to emulate the decision making and reasoning of a human expert.  In their simplest form, expert systems are composed of rules that read like simple "IF ... THEN ..." statements, such as:

  • "IF it is noon THEN eat lunch"
  • "IF the light is red THEN stop"
  • "IF the light is green AND a pedestrian is in the crosswalk THEN stop"

The "IF ..." is a question about one or more facts, and the "THEN ..." is the action to perform.  The rules are taught to expert systems by being programmed by a rules engine.

Clear as mud, you say?  If you really want to know more, there is plenty of information freely available online about this topic, however the only key understanding needs to be "IF ... THEN ...".

Benefits of an Expert System in Vulnerability Management

There are many benefits to using an expert system to solve a problem.  The top benefits as it relates to VM are explained below.

Powerful Simplicity

The core of each rule is simply a question and an answer/action.  The question can query one or more things about one or more facts and can be as simple or as complex as you like, ranging from "do we have a valid user for this asset?" to "do we have a valid administrative user and can this user read the registry remotely using CIFS?" and beyond. The answer/action is similarly flexible and can result in something simple, like storing the result of this reasoning somewhere, all the way up to something powerful like assertion of new facts.

What vs. How

An expert system allows the person or thing programming it to simply describe the "what" about the goal rather than the "how."  The "how" can be inferred by the expert system, often with help from other rules.

Take an overly simplified VM use case: Is a Windows XP SP3 asset vulnerable to MS08-067?  Assume there is simply one way of achieving this goal: by inspecting the registry for the presence of the registry value that indicates that KB958644 (the KB for MS08-067 on Windows XP SP3) has been applied.  Without using an expert system or technology with similar capabilities, even in this very simplified case, the "how" becomes quite complicated rather quickly as demonstrated by this pseudo-code:

obtain all valid administrative credentials  
discover all ways to read the registry  
for each method of reading the registry  
  for each valid administrative credential  
      connect to the registry  
      if value for KB958644 is present  
        read value of KB958644  
        if value of KB958644 indicates patch has been applied  
            asset is not vulnerable  
        else  
            asset is vulnerable  
      else  
        asset is vulnerable

Thanks to the expert system, the "how" becomes quite simple:

if value for KB958644 is present  
  if value of KB958644 indicates patch has been applied  
      asset is not vulnerable  
  else  
      asset is vulnerable  
else  
  asset is vulnerable

Furthermore, because Nexpose is a vulnerability management tool rather than an invulnerability management tool, the majority of its rules for vulnerability checking focus only on determining if an asset is vulnerable rather than invulnerable, thereby simplifying this even more.

Pluggable Components

Something that I glossed over when discussing the previous two benefits was that, when combined, these benefits allow decisions to be made regardless of where the facts or knowledge came from.  Take "for each method of reading the registry," as an example.  You can have other rules that are responsible for asserting facts/knowledge about the registry in all manner of ways (CIFS, WMI, running 'reg query' from a command shell, using MS SQL Server's 'xp_regread' stored procedure, etc). Then any rule that wants to interact with the registry can do so using knowledge from these facts, including the likes of the example for MS08-067 I gave previously.

How Does Nexpose use an Expert System?

The core of Nexpose's scanning is powered by Jess, a rules engine for Java.  Nexpose completes the VM scan by walking through the following phases:

  1. Asset discovery: What assets exist and are alive in the target site?
  2. Service discovery:  On each live asset, what ports are open?
  3. Service fingerprinting:  What is running on each open port on each live asset?
  4. Operating system discovery:  What operating system is each live asset running?
  5. Asset metadata discovery:  What users, files, directories, file systems, databases and software are on each asset?
  6. Vulnerability checking:  What vulnerabilities exist on each asset?

The definitions of the phases, their ordering, and the definitions of the rules that make up phases are all done in Jess in one way or another.  The rules that make up the rough six steps above are on the order of 150,000 today, the vast majority being those for performing vulnerability checks.

Example: Authenticated Patch Checking Without Providing Credentials

There is much more detail about expert systems, Jess and Nexpose's use of the two that can't realistically be described here.  Perhaps a more in-depth example will help.  Please realize that this is still largely simplified, however it should accurately demonstrate one of the ways in which Nexpose uses an expert system and how the benefits mentioned previously manifest themselves. Nexpose is able to perform the equivalent of authenticated patch checking in some situations even if a user does not specify credentials to use for authentication while scanning.

Assume the following scenario:

A Nexpose administrator is responsible for performing authenticated vulnerability scanning of a Windows network, however some of these machines are rogue and not integrated with Active Directory, therefore the scan credentials that could be used during scanning will not work.  The rogue machines are presumably misconfigured and missing critical security updates.

The following rough sequence of events occur when Nexpose scans these rogue machines:

  1. The assets are discovered to be alive during asset discovery
  2. TCP ports 135, 139 and 445 are discovered open during service discovery
  3. The ports from step #2 are fingerprinted and determined to be for WMI and CIFS, two administrative services present on most Windows assets
  4. By inspecting the fingerprinting results from #3, as well as IP stack fingerprinting, Nexpose is able to determine that these are Windows assets, however the exact version may not be known
  5. Because we were not given administrative credentials, no software, users, etc., are enumerated
  6. Vulnerability checking commences, however the only types of checks that run and return anything of value are those that don't require information available only with administrative credentials.  Among the checks that do run includes a check to ensure that the password for the Administrator account is a horribly insecure 'password.'  The host is marked vulnerable to this.
  7. Because step #6 discovered valid credentials, these credentials are then made available to anything which can use them.  Now the information and steps that didn't really run in step #5 run and users, software, etc are enumerated.
  8. The checks that did not run in step #6 now run and several high-profile, high-risk IE vulnerabilities are discovered to be unpatched, presenting a serious risk to the organization

Hopefully this gave you more insight into Nexpose and its internals.  Enjoy!