2

We're currently going through a process of using Qualys scans to find security vulnerabilities on Windows servers in our enterprise.

We are finding quite a number of older Windows applications on our servers that we think are being installed by SCCM.

Some examples of this are:

  • EOL/Obsolete Software: Microsoft VC++ 2005 Detected Microsoft

  • Foundation Class Library Remote Code Execution Vulnerability (MS11-025)

How can we find out which Windows applications have dependencies and which applications can be removed on our Windows machines?

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
Tikhon
  • 87
  • 9
  • 1
    if you are able to reproduce your setup you can use "monitoring" software installation tools. for example i used (a few years ago) add remove plus for detecting what actually was changed by an installation, resulting in a better deletion process after the program was removed again. You might be able to use the installation procedure to detect what was installed by that Programm as dependencies. Though this does not give you the info if that dependency is actually used by the programm. – Dennis Nolte Mar 02 '18 at 09:09

2 Answers2

3

Have you tried things like this?

If that doesn't work, do it the same way you set up whitelist based sandboxes... clone it to a lab environment, then remove things you probably don't need, and run your tests. Does it still work? Then you don't need it, even if it is explicitly documented that it needs it. But "works" is different from "appears to work but doesn't really", so be careful. And requirements can change.

Peter
  • 2,546
  • 1
  • 18
  • 25
  • You appear to be arguing the idea that Microsoft documentation is sometimes erroneous or incomplete. I agree with this sentiment. – Spooler Mar 02 '18 at 01:00
1

There isn't an easy way to find this information such as running a script or installing a third party program that will run a report. The best route is to:

  1. Identify Application to be tested and gather requirements
  2. Replicate any backend data such as cloning the database
  3. Bring up parallel server or virtual machine meeting the requirements from item #1
  4. Configure the application just as it is in production using the cloned data from item #2
  5. Test everything to ensure it works the same as production
  6. Perform your inventory
  7. Rinse & Repeat for the next application

The process takes time but its also a great opportunity to document the following points:

  • Application Requirements
  • Disaster Recovery Process
  • Stakeholders
  • Monitoring Points. From item #5, take the Unit Testing approach to automate this process the best you can using repeatable techniques. Then incorporate it into your in-house monitoring system.
user2320464
  • 759
  • 5
  • 14