- Creating a Custom Vulnerability Definition
This article illustrates how to create a custom vulnerability definition in Patch and Compliance Manager. Creating custom definitions is not part of the regular support that Ivanti offers, so this Community article will serve the purpose of assisting customers in creating these definitions.
In Ivanti Security and Compliance Manager the ability to create a "user-defined" vulnerability definition provides an extremely flexible and powerful tool that can be used to implement and maintain computers in your environment.
Create Custom vulnerability definitions (and detection rules) to scan managed devices for any operating system, application, single file, registry condition, or use custom VBScript for various conditions to have the client be detected in order to implement various solutions.
Implementations of the custom vulnerabilities are almost limitless. It can be used to update any application on managed devices. It can be used to apply any single file executable to a managed device based on detection rules defined by the Ivanti LANDESK administrator.
The following step-by-step example shows how to create a custom vulnerability to update or install a fictitious "in-house" application.
The administrator should be able to install the Ivanti Endpoint Manager Core Server and clients. The core and managed devices should be configured with the latest LDMS version and service pack.
Creating a Custom Vulnerability Definition
We will now create the custom vulnerability to detect a condition. In this case, Iwe will use "File Detection" logic to look for a minimum allowed version of "SuperSpecialInHouseApplication.dll".
- From the Endpoint Manager on the Core Server or a Remote console open the Security and Compliance tool group.
- Open the Patch and Compliance tool and click on the Create Custom Definition icon. (Green circle with + in the middle)
- The following window will open which shows the General information for your Custom Definition:
- Enter an ID, Title, Severity, and Notes. This will show up in your Custom Definitions list in the following way:
- Under Detection Rules click Add to add detection rules.
Detection Rule Help
Detection rules define the conditions that will cause the computer to be deemed "vulnerable" or simply needing an update, configuration change, installation of an application, etc.
Sometimes multiple detection rules are necessary to install patches, make configuration changes, based on conditions.
A common use of multiple detection rules is when you have separate patches for 32-bit patches and 64-bit patches.
The following Properties for Rule # window will appear.
Vulnerability definitions are processed from the top down, and the following detection checks are taken:
Selecting Affected Platforms
The scanner checks to see if the client is running an affected platform (in this case as defined by the user).
This is the operating system that is running on the client computer. It is possible to differentiate between 32-bit and 64-bit versions of the Operating Systems, Etc.
The following is an example of the Platform pick-list:
If the client computer is not running an affected operating system all other detection criteria is ignored and the computer is not deemed "vulnerable" as it has not met the first detection criteria.
It the client computer is running an affected operating system (platform) the scanning will continue to "Affected Products".
Creating a custom Affected Product
The "Affected Products" check is to see if the Product exists on the client computer. This is a top-level criterion, and will typically check for the mere existence of a file or registry key associated with the product. Sometimes a VBScript is used.
If writing a custom definition for a product that is already in the EPM database, you can simply click "Configure" and select that product.
Otherwise, in our case of writing a custom definition for "Super Special In-House Application" we will create a new Product based on file detection of "SuperSpecialIn-HouseApplication.exe".
- Click "Configure" in the Properties for Rule # properties window.
- Click Add and file in the ID, Name, Vendor, and Version information (as applicable)
Creating a custom product or selecting an already existing product adds another level of detection making other detection processes later in these steps more flexible.
For example, if the scanner doesn't detect that Super Special In-House Application is installed it will leave the detection process.
- Move down to the "Files" section of the Detection logic and enter SuperSpecialIn-HouseApplication.exe (or of course your filename you are concerned with).
- Enter in a range for the Minimum Version the file has to be and the Maximum version. In this case, we will enter 0.0.0.0 for Minimum version, and 22.214.171.124 so that any version found will be applicable.
- Click OK to save the newly created Custom Product.
- Now that the Product has been created, it will need to be included in the Rule. Select the new Product from the bottom pane of the Select Affected Products window and then click on Include to move it to the Affected Products pane.
- Click OK.
Now move down to the Query Filter section. All detection fields are optional. Typically the Query Filter pane is used to include or exclude clients from the detection based on EPM queries.
An existing query can be selected or a new query created. For our example, we will not use a Query Filter.
Files Detection Logic
- Move to the Files pane.
Our example will use "File Version" for detection. However, there are various methods of detection that exist file Files detection:
- Since SuperSpecialIn-House.dll is used in our detection process, and our new file is version 1.5, we will check to see if anything older than 126.96.36.199 exists. Note that the top of the window says "Detection will occur if any of these conditions are not met".
Several different criteria can be added (stacked up) in the File detection section. If any one condition is not met, the computer will be deemed vulnerable. However, typically only one criterion will be added here.
- For path, you can enter in a static directory and filename (C:\Program Files (x86)\SuperSpecialIn-HouseApplication.dll) or use variables. In order to use variables, right-click the FILEPATH entry and you will be presented with variables that can be used.
- In Min version enter "188.8.131.52". This will indicate that if the scanner sees any version of the .DLL that is earlier than 184.108.40.206 (the version of the .DLL in the update to be installed) the computer will be deemed vulnerable. For our example, we will not use the Registry Settings detection or the Custom Script detection however, if any combination of detection criteria for all three detection types are not met, the computer will be deemed vulnerable.
There is an important difference between "File must exist," "File must NOT exist," and "File may exist":
- "Must" means that the file needs to exist. If it does not exist the computer is deemed vulnerable. This is important because if you have not defined a product and are simply using detection criteria. The fact that a file does not exist will cause the computer to be detected to be vulnerable, even if an affected product is not installed.
- "May" means that if the file does not exist, that is fine - detection will not happen and the computer will not be deemed vulnerable. However, if the file DOES exist, the detection criteria must be met, in our case the file must be at version 220.127.116.11 or higher or detection will occur.
- "Must Not" means that if the file is detected, it will be ignored and the computer will not be deemed vulnerable.
There are three options available regarding Patch Information:
- "Repairing this issue requires downloading a patch" is used when you want to install a patch, an upgrade file, or an application.
- "This issue can be repaired without downloading a patch" is used when you intend to use scripting, additions/changes to the registry, copying files, starting or stopping a service, etc to "repair" the computer.
- "This issue cannot be repaired by Security and Compliance Manager" is used when you simply want to use detection only and do not plan to patch, upgrade or otherwise configure the client.
For our example, we will use the "This issue requires downloading a patch".
- Select "This issue requires downloading a patch"
- If you have a source to download from, enter the FTP or HTTP address into the "Manufacturer's patch URL:" section.
- Select "Auto-downloadable" and set it to "Yes". If the patch is not downloadable, the patch file will need to be placed in the default patch location. (Also see this document: How to change the default Patch Location for Patch and Compliance Manager)
- Each file that is installed by Patch Manager must be given a unique filename when it is downloaded. This filename can differ from the original filename that existed on the source for the download. Enter in a unique filename or the existing filename if manually copying the file into the default patch location rather than downloading from an FTP or HTTP source.
- Once the file is in place, you will need to generate a hash for the file to ensure that it is secure and cannot be replaced with another file surreptitiously.
To do so, click the Calculate Hashes button and you should see the red X's above turn to a green checkmark, you will also see the "File Size" line populated with the file size.
- If your application requires a reboot, enter the appropriate choice in the "Requires Reboot" section.
- If your application can be installed silently select the appropriate choice in the "Silent Install" section.
(Note: These fields are used for purely informational purposes. The "Patch Install" section of the rule controls the silent switches, and the Distribution and Patch Settings control the reboot options.
Detecting the Patch
Various criteria can be used to detect whether the patch is installed. Both File Detection and Registry Detection can be used. This detection criterion is the opposite of the detection criteria to detect the vulnerability. Note that this section says "The patch will be detected if all these conditions are met, along with all registry and script conditions". The Detection Logic section says if the criteria is NOT met. This is an important distinction. Due to this, the exact same criteria can possibly be used both in the Detection Logic section and in the Detecting the Patch section.
Patch Installation and Removal
If processes need to be stopped prior to your install, update or configuration change, you can list the process name as it would appear in Task Manager in windows. Several entries can exist.
This will cause any of these processes to be "killed" (stopped) prior to the patch install actions.
This will allow you to specify additional files that will be downloaded to the client along with the main file that is listed under the Patch Information section. Enter the HTTP and/or UNC path, then click the blue arrow to browse to that location and then select the file(s) you wish to include from the "Available files" listing. After adding the files you will be presented with options to hash the files.
Patch Install Commands
Various combinations of actions can be added to the Patch Install commands section:
As in other areas of the Rule properties, variables can be used, this is typically displayed by right-clicking an appropriate field such as "Path".
Patch Uninstall Commands
Path uninstall commands are the same as the Patch Install commands. A combination of actions can be defined to uninstall a patch, undo a configuration change, etc.
Tips and Tricks
In order to see examples of vulnerability definitions and rules, you can right-click any existing definition (custom or not) and select "Clone". This will create a duplicate of the definition that will show up in the Custom Vulnerabilities category and can be edited.
This is a great way to learn how to create detection logic and installation commands.