Reporting Toolbox - Best Practice: Always Report on EOL Product QIDs

Document created by Martin Walker Employee on Jan 15, 2018Last modified by DMFezzaReed on Aug 20, 2018
Version 6Show Document
  • View in full screen mode

I am frequently asked whether or not Qualys produces QIDs for products that are EOL.  In addition, I occasionally see a customer who ignores or otherwise does not report on or count in metrics EOL product QIDs.  This article explains our approach to QIDs for EOL products, and why ignoring or not reporting EOL product QIDs is inappropriate.


How Qualys Handles EOL Products

In general, once a particular product is EOL and no longer supported by the manufacturer Qualys does not produce any new QIDs for that product.


Part of the reason is that ultimately every product and every software package becomes EOL.  It is clearly not feasible to continue to generate and test QIDs, which in turn means having that product in-house and being able to test against it, for an ever-increasing list of products and software that have an ever decreasing population of users.


When a product goes EOL we produce an EOL product QID.  Since the vendor (with rare exception) does not produce patches for EOL products, the recommended solution for any new vulnerability related QID for that product would always be “Upgrade to the latest version”.  This is already the recommendation for the EOL QID, which is a Severity 5 Confirmed QID.  So, adding additional QIDs for newly discovered vulnerabilities in EOL software would add minimal information to your vulnerability data at a significant cost.


When EOL Products Get Patched

On the relatively rare occasion that there is a significant high profile public exploit against an EOL product, we do create a detection for that vulnerability. One example is the Shadow Brokers (ETERNALBLUE) security issue.  Qualys originally flagged QID 91360 against Windows XP and Windows 2003, EOL products, since those machines were also vulnerable and there was a proof-of-concept code available.


When Microsoft realized how significant the number of customers still using Windows XP and Windows 2003 is, they publicly released security patches. Our detection was then modified to account for those available patches.


There are vendors who offer private contracts with customers to support End-of-Life products.  Qualys has no insight into those programs.  Those programs are costly and, in our experience, extended support program includes covenants which restrict the sharing of information about vulnerabilities and patches.  Since we do not have access to EOL patches, we cannot develop and test QIDs against them.


Best Practice Recommendation

In summary, while Qualys does not generally produce individual vulnerability related QIDs for issues discovered in EOL products, each product will have a Severity 5 Confirmed EOL product QID.  It is important to understand what this means, and not mask or ignore those QIDs because of a misunderstanding about “increased vulnerability count”.  Having an EOL product in your environment is a risk, vulnerabilities or not.  If that product is widespread, and particularly if that product is tightly integrated into your production environment (e.g. a middleware product), it is critical to not lose sight of the risks presented.  Keep the issue visible and plan for an orderly replacement, rather than waiting for a critical vulnerability to be discovered.







Back to Dashboarding and Reporting

4 people found this helpful