Summary Sometimes you need to publish a package that hasn't yet been installed on your hosts. As such, this new deployment needs to pass WSUS/SCCM applicability checks and installs when it is being deployed. This article guides you on how to create such packages and use the SVM Software Package System not only to publish security updates, but to publish all third-party updates you want. Synopsis The Flexera Software Package System is a powerful tool to deploy security updates, but not only that in fact. SPS allows you to also configure New Custom Package that can be deployed based on your judgment, and not only based on what SVM detected in your network. This gives you the chance to utilize the package integration of SVM with WSUS/SCCM to further publish brand new deployment packages to hosts that hadn't had those installed prior to that. For this purpose, you only need to perform certain configuration of your new Custom Package to be able to utilize it properly. Even though each package published via SVM requires to be wrapped in a script similarly to how update packages are done, you don't really need to script it yourself, just use a little trick. You can copy the script from any Update Package in SPS and further place it accordingly in the configuration of your new Custom Package, to get it working just fine. Discussion Before creating the new Custom Package, you must ensure certain prerequisites that are mandatory. Download the executable file of the program you are to distribute. Alternatively, find the direct download link of this program which can also be used in your package. Determine the correct silent installation parameter that works for this package - it's mandatory that it has one. If the program does not support silent install, this package cannot work on hosts. Create a WSUS group or SCCM Collection (depending on what you use) that gathers precisely the hosts that are intended to receive the new custom package installation. Consider that your package will deploy to any machine that is being targeted - neither WSUS nor SCCM will have any evaluation control over this package after it's published. You must, at the very minimum, have at least one blue program entry listed under SPS central view - it could be any program e.g. Adobe, Java, VLC - you'll use it to copy its script. Workaround Once you've made sure the prerequisites are met, the following steps are your course of actions: Go to SPS view and right-click on any blue program entry. Select 'Create Update Package' and accept the following warning screen that may appear. Enable the 'Edit Package Contents' checkbox at step 1 of the SPS Click 'Next' to move to step 2 then. Copy the existing script in the 'Execution Flow' window starting from the 5th line, which is the first line with comments under 'OptionalParams' variable. Cancel the package wizard after you've copied the script. Return to SPS central view Find the button 'New Custom Package' at the top frame of the central view and click it. At step 1 of the new package wizard, enable 'Edit Package Content' checkbox (and enable the 'Use Flexera Custom Naming' if deploying via SCCM). At step 2, paste the script that you've copied earlier into the 'Execution Flow' script. Select everything starting after the 3rd line ('Var optionalParams') and paste the previously copied script on top of it. Use the 'Add Local File' button under the execution flow to integrate your program installer in the package. If you prefer using direct download link, use the 'Add Download Link' button to paste it there. Look at Line 3 of the Execution Flow script named 'var optionalParams = ""; You should add the mandatory silent installation parameter that corresponds to your package. Add it in-between the quotes e.g. "/S"; (given that /S is the correct one) Click the 'Create SPS File' button to export the current package configuration on the file system. Take the sps.exe exported file and execute it on client that does not currently has your application installed. If the 'sps.exe' exported file install silently and directly as you run it, your package is ready to deploy over SCCM or WSUS. If you encounter an error, you should revise the silent parameter and you should confirm that you copied/pasted the script precisely as instructed above. Click 'Next' at step 2 to move forward. At step 3, mandatory tick the checkbox 'Mark Package as AlwaysInstallable' You can continue with 'Next' until you 'Publish'. Only approve this package in WSUS for Groups (or send it to collections) where all hosts to the very last one are intended to install this package. This package will not be regulated by your deployment server like Update Packages usually are. Additional Information This functionality is provided and used 'as-is' and Flexera support does not take course to troubleshoot failing custom packages. The current guide is provided for users' convenience and for usability purposes, but users are strongly advised to perform package testing before deploying. Using the Create SPS Package function at step 2 allows you to easily export, test and confirm the package applicability. Make sure it is being used each time. You should expect your package to install at its default directory as being implemented by the vendor. ... View more

Problem Formulation Flexera understands the desire for coverage of Red Hat OpenJDK but is unable to effectively track it on Windows systems due to inconsistent and conflicting identification information coming from Red Hat. While we do cover it on RHEL, we cannot adequately cover the Windows versions with Secunia Advisories. For us to reliably track Windows versions of Red Hat OpenJDK in our SVR and SVM products, we require Red Hat to improve their security reporting process. Flexera is reaching out to Red Hat to encourage more consistent handling of non-RHEL based versions of OpenJDK, but we also encourage any interested customers of Red Hat to do the same. Reporting Quality Red Hat security advisories aim to report on security issues with the products that distribute Red Hat OpenJDK packages [1], e.g., Red Hat Enterprise Linux products but do not report on Red Hat OpenJDK itself as a full product. There is factually no dedicated reporting of security vulnerabilities in the product OpenJDK for Windows systems coming from the originator/maintainer vendor Red Hat. [1] https://access.redhat.com/errata/RHSA-2019:0790 This problem makes the process of ascertaining which versions of OpenJDK have which vulnerabilities (on which platform) very unreliable – distribution version of packages on RHEL and “upstream” version releases differ broadly, and so do their weaknesses. Without a reliable product-focused security reporting on OpenJDK for non-RHEL versions (like the Red Hat does for JBoss for non-RHEL platforms), Flexera may not directly translate the upstream release cycles of OpenJDK to Red Hat security reporting. Examples Recently, we have seen the following vulnerability reports that may be relevant for Red Hat OpenJDK (officially supported on Windows platform by Red Hat); however, the CVE identifiers reported per platform are not consistent: Red Hat Security Advisories (RHSAs) like RHSA-2019:1840 seem to only cover the distinct OpenJDK package relevant for RHEL, however, not for the Windows platform. These RHSAs look to at least cover, e.g., the related Oracle Java CVE identifiers applicable to OpenJDK. Release notes for Red Hat OpenJDK like this one may feature CVE identifiers irregularly. However, there doesn’t appear to be Oracle Java-related CVE identifiers listed as one should expect. In the example, the CVE identifiers appear to be “icedtea-web” / Java WebStart related. The CVE-based links Red Hat provides in this context only report RHEL-based packages and not Windows platform. Recommendations We have contradictory vulnerability information regarding Red Hat OpenJDK for Windows. We have no source that states which Oracle Java-based CVE identifiers are affecting the Windows platform, in which version and Red Hat does not clarify which may be applicable. The outcome is that we cannot ensure accurate vulnerability reports for Red Hat OpenJDK running on Windows, rather than risk providing inaccurate research. Flexera is required to exclude Red Hat OpenJDK for Windows from its tracking service until Red Hat resolves this. As a Red Hat customer, you have the power to help encourage Red Hat to track and report the product consistently, and so we encourage you to do so as well. Good Alternatives An alternative to the Red Hat's OpenJDK is the "Amazon Corretto JDK" package, which was already added for vulnerability tracking in the Flexera SVR database. Furthermore, Flexera currently evaluates the possibility of adding scan detection signatures and version security rules for the SVM 2019 product too. Customers who need to track and utilize an OpenJDK alternative for Java, are recommended to research Amazon Corretto as they will not have a problem with receiving vulnerability advisories with that package through the SVR and SVM products of Flexera.  ... View more

Users often require additional help for the logical process workflow when it comes to integrating the Software Vulnerability Manager 2019 software to their internal WSUS or SCCM servers for patching. In most, users need additional elaboration on what is the right sequence of steps to integrate SVM and what actions will be needed to troubleshoot expected errors that come in their way as part of the deployment process.  Flexera has made a logic flow map that provides essential knowledge of the steps involved to integrate the SVM to your internal server infrastructure and the steps to troubleshoot basic errors or exceptions that might come in your way while you're performing this process. We also provided an extensive amount of additional information that can help you investigate package errors in the different phases of the deployment process of a package made with SVM and handled for deployment in WSUS/SCCM/CCM. Customers are highly encouraged to follow this diagram at their best effort, before reporting support cases to Flexera Support, as they would also receive a greater knowledge in learning each step of the integration while following the diagram.  You can download the attached PDF document under this KB for a better resolution of the logic map.  Customers are highly advised to include the relevant log files that enable visibility when they send their cases to the Flexera Support team. Depending on where the problem occurred (in which phase), the following log files can be relevant: 1. Patch Creation phase:  If there was a technical problem not covered by the logic flow map, the first course of action should always be to search the error you see inside this Flexera Community site, as Flexera Support issues KBs for each new error that is detected with customers. The chance of finding a solution here is very high.  If that did not help you solve the issue or move further in the mapping process, find the "%userprofile%\My Documents\csi_pluginlog.txt" file on the system where you tried creating a patch and submit that to our Support team adding as much as information about your case as possible.  2. Patch Deployment phase:  The patch was published successfully, but there is an issue with your WSUS server not sending the update to the recipients you approved it for. This may be expected if the recipients did not have the same software already installed (hence, the patch is not applicable, that's why it is not showing up). This is where you have to check the patch applicability rule configured in the SPS wizard -> steps 3 and 4 and verify all enabled requirements of the patch against the clients not receiving it.  If the patch was published to SCCM, you should first and foremost ensure that your SCCM/WSUS (SUP) configuration is intact. If it is and you're successfully publishing Microsoft patches that way, then you can troubleshoot the wsynclog.log file for errors that might shed more light on what is causing a problem with the synchronization of the patch between the WSUS DB and the SCCM's own database.  3. Patch Download/Installation phase:  If the patch has shown up and you've deployed it to hosts, but the hosts failed to install it, you can look into the respective client logs for the CCM Client service, Windows Update, or the Secunia Logs as well: a) Check C:\Windows\SecuniaPackage.log for any traces of installation - did package ran to install? - If it ran - patch applicability rules are fine - there's an execution error, however.  - If it did not run at all and there are no traces of that - there are most likely patch applicability issues or management point download issues. Such problems can be diagnosed in the log files (to name a few): C:\Windows\CCM\Logs\UpdatesDeployment.log C:\Windows\CCM\Logs\UpdatesHandler.log b) If the patch ran and there's an obvious error in the SecuniaPackage.log file - check the "C:\Windows\WindowsUpdate.log" file next. You can also find more information on the CCM->WUA patch passing in the C:\Windows\CCM\Logs\WUAHandler.log file. Windows Update is the last service to touch the patch upon execution and the first one to handle the incoming errors - disregarding if you use SCCM or WSUS - that's the case for both scenarios. This log file will contain many lines of error description that you can check against MS Technet first.   c) If you deploy patch via SCCM and your WUA service, CCM service, and SecuniaPackage.log all indicate that the package was installed correctly (hence, exit code = 0), but your SCCM is showing wrong compliance of the patch, then you are likely to be looking at a known bug in the CCM "state message" handling of the CCM service that transmits the wrong execution status to its server (for which you can only talk to Microsoft about as Flexera cannot be helpful to solve known CCM-related bugs). This issue can be identified using some of the following logs: C:\Windows\CCM\Logs\StateMessage.log C:\Windows\CCM\Logs\SCNotify_<domain>@>WindowsUsername> C:\Windows\CCM\Logs\SCClient_<domain>@>WindowsUsername> as well as the following local WMI classes where CCM stores the incorrectly handled package execution status, and the incorrect state messages being sent to the SCCM server database (to name a few): root\ccm\SoftwareUpdates\UpdatesStore -Class CCM_UpdateStatus root\ccm\SoftwareUpdates\DeploymentAgent -Class CCM_TargetedUpdateEx1 root\ccm\SoftwareUpdates\DeploymentAgent -Class CCM_AssignmentCompliance root\ccm\ClientSDK -Class CCM_SoftwareUpdate root\ccm\SoftwareUpdates\WUAHandler ... View more

The Monthly Vulnerability Review blog aims to deliver security insights derived from analyzing the software vulnerabilities processed, analyzed, and verified by Secunia Research at Flexera each month. By doing so, we aim to present the bigger picture that can serve as a baseline for organizations to adopt better vulnerability management strategies, as we also deliver ultimate insight on which vendors are most often being vulnerable. Flexera discloses vulnerabilities through its proprietary Secunia Advisories (SAIDs). One Secunia Advisory can report on one or more software vulnerabilities. When there is more than a single software vulnerability contained in a given advisory, the “Title” of the SAID will indicate “Multiple Vulnerabilities.” When there are multiple products reported in a single Secunia Advisory, the title will mention "Multiple Products." Additional details about the proprietary Secunia Advisory can be seen in our first blog edition.  Monthly Advisory Overview Between October 1 – November 1 of 2019, there have been 441 new Secunia Advisories processed by Secunia Research. That represents a 9% increase from September to October. Of the total 441 advisories, 27% reported multiple vulnerabilities in each separate Secunia Advisory. 37.1% were attributed only to Linux-based software packages for the various distros tracked in the Flexera software vulnerability database. The remaining 276 SAIDs (62.9%) cover all other software products, operating systems, and platforms.  Linux Kernel flaws and software vulnerabilities found in various Linux operating systems have not been included in the previous 37.1% statistic, and are accounted for in the 62.9% altogether with the rest. Products and Vendors  Flexera has attributed the 441 advisories to 377 different software product versions, from 296 unique product titles, released by 74 different vendors. While there have been five vulnerable vendors less compared to the data from September, we saw an increase of 33 more product titles from 263 to 296 in October, and also an increase of 22 product versions from 355 to 377. In October, Oracle Corporation had most security advisories attributed to them with a total of 55 SAIDs. They’ve had 13 SAIDs more than what Cisco had on their name, and 17 more than Amazon and IBM. In percentages, Oracle holds 12.47% monthly advisory share, Cisco has 9.52%, while IBM and Amazon have 8.62% each. With Red Hat’s 6.82%, the top 5 vendors held 46.05% of all Secunia Advisories processed by Flexera that month. Advisory Criticality  We made a breakdown of the criticality ratings assigned to all Secunia Advisories processed by Flexera in October of 2019. There have been no Extremely Critical advisories, 17.91% SAIDs have a Highly Critical rating, 36.28% Moderately Critical, 35.15% Less Critical, while the remaining 10.66% advisories classified with the Not Critical rating by Flexera. The numbers on the right side provided below show the increase or decrease in the advisory counts between September and October months. “Extremely Critical” = 0               (-)                           “Highly Critical” = 79                    (-13)                      “Moderately Critical” = 160       (+19)                     “Less Critical” = 155                     (+30)                     “Not Critical” = 47                         (+1)                        We analyzed the average criticality rating per advisory assigned to the top 25 list of vendors with most Secunia Advisories attributed to them. "Blank" refers to a collection of "various open-source software" such as Jenkins, Go, Piwigo, Netty, etc. and not to a single vendor as it is the case with the rest in the list. The light-blue numbers display the amount of Secunia Advisories attributed to each vendor, while the dark-blue numbers indicate the average per-advisory criticality rating result. Adobe Systems, Mozilla Foundation, Google, and Apple topped average criticality per the advisory, with all of them sharing a “Highly Critical” rating. The last entry in the top-5 criticality list goes to Microsoft based on a criticality rating average of 2.636 per Secunia Advisory. Criticality average of 2.636 out of 11 advisories means that almost every advisory attributed to Microsoft has a Highly Critical rating.  Because Apple had more advisories than the first three vendors, and few less than Microsoft, it ranked as the most critical vendor to handle among these five titans of modern-day software. We must also note that those vendors had significantly fewer Secunia Advisories attributed to them than the vendors in the top 5 which would normally play a role in the average measurements and comparisons.  For the record, a criticality rating of 1 translates into "Extremely Critical" (e.g., priority 1), while the criticality rating of 5 translates into a "Not Critical" rating as per the Secunia Research assignments. Attack Vectors  In October, there has been a significant increase in remotely exploitable vulnerabilities. There was a 4.6% increase in the overall monthly share of security advisories reporting vulnerabilities identified as remotely exploitable. It reached 64.85% (286/441) in October, while the monthly share for September was 60.25% (244/405). The difference of 42 SAIDs represented an actual 17.1% increase from September to October in the count of advisories that contain remotely exploitable vulnerabilities. Another 23.81% advisories disclosed on software vulnerabilities identified with the “Local Network” attack vector. The security advisories reporting vulnerabilities exploitable from “Local System” were a total of 11.34%. CVSS3 Scores We’ve made a breakdown of the CVSS3 scores of all October advisories into three specific ranges: Low Severity Range (CVSS3 0-4) Medium Severity Range (CVSS3 4-7) High Severity Range (CVSS3 7-10) Because Secunia Research assigns CVSS3 scores on an advisory level, this breakdown helps us to identify which CVSS3 range had a predominant amount of Secunia Advisories each month. In October, 4.1% of all advisories resided in the low-severity range, 38.5% resided in the medium-severity range, and 57.4% resided in the high-severity range. The following sums up the exact count of advisories in each range: SAIDs in the Low CVSS3 range = 18 (-11) SAIDs in the Mid CVSS3 range = 170 (+42) SAIDs in the High CVSS3 range = 253 (+5) Next to the main numbers in bold, you see the increase or decrease in advisory counts as compared to the month before. We can spot a pattern where forty-two extra Secunia Advisories have been added to the medium-severity CVSS3 range, reminding us of the 42 advisories added to the “From Remote” attack vector percentages that we saw earlier.   That is a strong indication that many, if not all, the newly added remotely-exploitable vulnerabilities resided in the medium-criticality CVSS3 scoring range, judging by the patterns seen in this analysis. That should lead to an increased focus on the less-severe weaknesses, because overlooking such flaws may have dramatic consequences to every organization that neglects the mid-ranges (you WannaCry?).  Adobe Systems, Mozilla Foundation, Google, and Apple were the most severe with an average CVSS3 of 9 per the issued advisory, but that is because they had a lower number of advisories attributed to them.  Still, the most severe was Apple due to having had twice as many advisories as the first three. From the vendors with the highest number of reports, Amazon Linux flaws have been more severe than others, as this vendor ranked a top performer in SAID counts, criticality, severity, and remote attack vectors too. Monthly Vulnerabilities  During October of 2019, Secunia Research detected, verified, and disclosed on at least 1362 unique standalone software vulnerabilities represented by that much unique CVE identifiers. That is a base minimum that you should consider because Flexera also reveals on software vulnerabilities that do not have a CVE identifier (yet). Those vulnerabilities have not been included in our blog analysis. Of the 1362 unique vulnerabilities with a CVE ID, 29% have been reserved and disclosed in previous years, also referred to as “alienated vulnerabilities.” The remaining 71% are vulnerabilities that have had their CVE ID reserved and reported publicly as an active vulnerability in the year we are in now – 2019. If we analyze the 1362 security flaws on average against this month’s vendor and product data, we can measure that there has been an average of 18 software vulnerabilities per vendor (74), nearly five software vulnerabilities per product title (296), and about four vulnerabilities per product version (377). However, this is the case only if we measure one unique CVE as one standalone vulnerability. That is simple math that allows us to make a fundamental analysis of the monthly security risk as a minimum. Still, it does not yet reflect the real big picture as realities on the vulnerability landscape are different. The reality is that many vulnerability IDs can (and usually will) be replicated across multiple Secunia Advisories because a single CVE ID can often affect more than one software product and vendor. An example of a few CVE IDs that exposed dozens of vulnerabilities in different vendors and products could be Intel’s Fallout/RIDL/ZombieLoad side-channel attacks. In the next screen, we make an example with one of the four Intel MDS CVE IDs, CVE-2018-12127, which affected dozens of products and vendors, for as many as 75 different SAIDs (until today and keep counting): If we identify the number of vulnerabilities using the correct logic as explained here, the actual amount of software vulnerabilities detected and disclosed by Secunia Research jumps up to 2432 vulnerabilities. The vulnerability counts for October, as seen through the data analyzed by us, represent a 39% increase in the standalone unique CVE ID counts from September to October (1362/978), and a 37% increase in the actual amount of detected by Flexera product-based vulnerabilities (2432/1778). That covers Linux-based software packages, all operating systems, all platforms, and all software products altogether. Threat Intelligence Overview Threat Intelligence Module leverages machine learning, artificial intelligence, and human curation from thousands of sources in the open, deep, and dark web. The module augments Software Vulnerability Manager’s world-class vulnerability intelligence with a threat score that provides the ultimate prioritization tool for your busy desktop operations teams.  In October, 52.15% of all Secunia Advisories have disclosed on at least one vulnerability that has any evidence of a known exploitation threat. The remaining 211 advisories have not been linked to a known threat yet. Of the 52.15% advisories with a positive threat score, we can analyze the following statistics: 187 advisories reside in the low threat score range 37 SAIDs live in the medium threat score range 3 advisories reside in the high threat score range 3 advisories reside in the critical threat score range Vulnerabilities in 185 advisories linked to a historical cyber exploit Vulnerabilities in 92 advisories related to recent cyber exploits Vulnerabilities in 82 advisories related to Penetration Testing tools Vulnerabilities in 22 advisories linked to a to Malware Vulnerabilities in 3 advisories have linked a to Ransomware. Additionally, Flexera has observed through its Threat Intelligence module at least 17 different malware families linked to a subset of CVE IDs that appear to be easily targeted and easily exploited by more than one malware family at a time. This information is available through the Flexera SVR REST API by dumping the full month data locally and performing an additional post-analysis of the malware titles linked to each advisory. SVR customers who have Threat Intelligence module included with their software can request more details on how this is scripted by contacting Flexera Support about it. Time-To-Patch In October, 88.44% of the released Secunia Advisories have a patch provided by the vendor. These advisories contained 93.87% of the vulnerabilities detected by Secunia Research at Flexera that same month! That leaves only 6.13% of all vulnerabilities reported over a whole month without a direct patch solution. For those flaws, you can apply a workaround where needed and where possible. The amount of detected and disclosed vulnerabilities indeed goes higher and higher in the past many years, but that is a good thing because it demonstrates that there is more quality security vulnerability research. The vendors and the security community are discovering more security flaws. Patches are coordinated accordingly to the responsible disclosure principle in a timelier manner, also thanks to specialized websites that help intermediate vulnerability coordination in favor of speed, simplicity and to ensure that security researchers are rewarded accordingly for their consistent research work. That leads to an increasing amount of software vulnerabilities that have a vendor patch on the day of the public disclosure. 93.87% of all vulnerabilities having a vendor patch is massive news in terms of the current situation of a high vulnerability increase from one month to another, but also a historical aspect. There is no better moment of emphasizing on the importance of vulnerability patching. Flexera has the solution capabilities of delivering verified actionable vulnerability intelligence to your doorstep in a mostly automated fashion. It also has the means and capabilities to offer the most extensive collection of ready-to-deploy software packages through the Software Package System (SPS), and the Vendor Patch Module (VPM) provided through the Software Vulnerability Manager solution. There is no better time for organizations to look at upgrading their patch management technologies. Only 1 out of 20 vulnerabilities does not have a patch provided by the vendor. Many times, this 1 security weakness will have a workaround or partial fix. Flexera can help organizations simplify their patching effort and achieve appropriate and very needed automation of detecting vulnerabilities and prioritizing a security patch against them, through an intelligent and fully integrated to your domain manner, for as many as 1.000 software product versions in several hundred unique product titles available through the SVM Vendor Patch Module and SVM Software Package System.  That is a resource that should be used for everyone's advantage, as much as possible, in times when security breaches make the news headlines every single day. There has always been a general lack of extensive amount of third-party software patches that can be tied to the security posture and prioritized through a single interface to drive domain security faster at its very core. By providing such capabilities, Flexera already helps many organizations gain a timely advantage against hackers to minimize their software attack surface to a minimum by assisting them to remain protected at the root on an ongoing basis. ... View more

Question: You have published Software Vulnerability Manager patches to System Center Configuration Manager and the patches had installed nicely on corporate systems. The System Center server is showing the packages' installation statistics, but the "Available" menu in the Software Vulnerability Manager does not seem to reflect that data and you cannot evaluate installation success from the SVM interface. How do you make the Software Vulnerability Manager read the SCCM data and reflect it? Answer: SVM normally reads the installation data from the WSUS database. SCCM does not mandatory push installation statistic data to WSUS unless you enable that optionally in the Software Update Point configuration of your SCCM server after having planned how much data that will load at the WSUS DB.  1. Open the SCCM Administration console and navigate to the Software Update Point configuration.  2. Enable the WSUS reporting events on the first page after the configuration window opens. ... View more