We have compiled a list of a few questions that you may have for Patch Management.
Currently, we do not have a mechanism that support the functionality where a mandatory sequential reboot is required between 2 patches that are a part of the same job. This functionality is not factored because it contradicts the basic philosophy of single reboot after an entire job, instead of after each patch is installed.
Patch Management does not install a software but only upgrades it to a newer version. It is extremely rare that a software version has no vulnerabilities associated. However, there might be vulnerabilities associated in future. To ensure future vulnerabilities are effectively remediated, we recommend regular and frequent patching for a software version.
We sync and update the catalog 30 minutes. However, sometimes a patch might take more time to reflect in our catalog. Depending on the vendor, the maximum time taken for a patch to reflect in our catalog is tentatively, 24 hours.
The Failed Patch Installs widget is not clickable by design. It just gives number of patches which failed to install overall in the account. The date range filters are not applicable for Patch Management widgets.
Yes, the patch install job proceeds to download and deploy patches even if a computer is locked or you are not logged in. If you are not logged in, the deferment option is skipped, and the reboot countdown is initiated immediately. Deferring a reboot is permitted only for a limited period to ensure quick closure on remediation, within the defined time (maximum 168 hours). Also, if the Suppress Reboot option is enabled, then the locked system does not matter, you must reboot manually.
A modification to a job (disable or delete) is ideally expected to be updated anywhere between 5 to 30 minutes. Server sends the job 3 hours prior to the job start date time. If the job is in agents’ queue and the job is deleted or disabled from the UI, then the time for new job manifest to reach agent depends on following:
- Time it takes to send the updated manifest to Cloud Agent UI and server
- Network connectivity
- Agent must be communicating to the server
- Next CAPI call of agent
If the agent receives a new manifest before starting execution of the job, it will remove the job from its queue. If not, then the job will continue taking the time it needs.
A deployment job execution is in 3 main stages:
1. Download of Patches
2. Deployment of successfully downloaded patches
3. Optional reboot after deployment based on the patches successfully deployed
A deployment job can be cancelled only before its scheduled time or before start of the second stage, that is deployment of patches. After initiation of the second stage, a deploy job cannot be canceled.
The reason is that the vendor does not store multiple versions. For example, Chrome will publish the binaries for all its patches using the same URL that is the same file. As such the agent can only download the latest version that is offered by Chrome and has no access to old versions.
While executing a deployment job, the agent checks if the patch binary file is signed or not. If the signed information is not available for a patch, checksum is compared for the file integrity. In case the patch integrity fails, the agent marks the patch installation as failed with following error codes:
To detect and patch a cumulative update, some Servicing Stack Updates (SSU) are a prerequisite. For best performance, Microsoft recommends that you apply the SSUs before installing the monthly cumulative update.
The reason is that the vendor does not store multiple versions. For example, Chrome will publish the binaries for all its patches using the same URL that is the same file. As such the agent can only download the latest version that is offered by Chrome and has no access to old versions.
On Windows assets, once the Patch Management is enabled on the agent, we detect the previously installed patches irrespective of who applied them.
On Linux assets, we do not detect previously installed patches. We report missing patches based on vulnerabilities in the system within 4 hours of detection.
An irrelevant or not applicable patch for an asset will generally show as 0 Missing and 0 Installed.
Yes, you can add QQL for a Windows deployment job instead of patches to select dynamically applicable patches for your environment. A QQL allows you to choose patches based on application, severity, vendor, and so on. A well-defined QQL can provide a sliding window of time to select patches published in a limited period like the last 3 months, 1 week, etc.
We store the patch supersede information in the patch catalog. And we store the count of non-superseded missing patches count when we receive the patch scan results from the agent.
If the vendor publishes the new superseded patches, then the same is applied in the patch catalog. But the non-superseded missing patches count is calculated only when we get the next agent patch scan results. Till we get the patch scan results, the previous count is shown.
It is essential to let users know about the possibility of a reboot in advance because though a reboot is inevitable, it might cause interruption to the business. Reboot Maybe Required alerts users about a possible reboot after deploying the patch.
For vendor patches, the reboot requirement can be ‘Yes’, ‘No’, and ‘Maybe’. Some vendors specify the reboot requirement as ‘Yes’ or ‘No’, and some mention it as ‘Maybe’.
A reboot is required for certain OSs, architectures, or processors, and for certain ones, it is not required. Hence, some vendors specify the reboot requirement as ‘Maybe’. It's complex to elaborate on this. So to simplify, they specify the reboot requirement as Maybe.
As ‘Maybe’ has unpredictability associated with it and is ambiguous, and clarity and predictability are highly expected, we chose a conservative approach.
For Qualys Patchable patches, Maybe is mapped as Yes so that users are never caught off guard and have a clear simple status.
If there is even one single scenario wherein a reboot is required, Reboot Maybe Required is shown as Yes.
Note: The Reboot Maybe Required is a possibility, not an assurance. The simple implication of it is that though Reboot Maybe Required is specified as Yes, a reboot might not be required at the run time. To sum up, the reboot requirement is evaluated at the run time during patch deployment.
For deployment job results along with actions, if eligible, the data retention period is set.
- For monthly jobs, the data will be retained for twelve months from the creation date. The data that is older than twelve months will be deleted.
- For other jobs, such as run-once, daily, or weekly, the data will be retained for six months from the creation date. The data that is older than six months will be deleted.
The Next Trigger details represent the date and time when the manifest is sent to the agent. The manifest is sent approximately three hours before the job starts.
The Start Date time details represent the date and time when the job starts.
Note: Irrespective of the system time zone, the Next Trigger and Start Date time details are shown based on the browser time zone.
