As part our Patch Tuesday efforts, Readiness has been “tasked” by Microsoft to develop a solution (in conjunction with our technology partners) to support the “containerized” application model.
Image Sourced from Liquidware “Developing a Comprehensive Windows Application Strategy“
What is unique about this new requirement, is that part of the Assessment stage, there must be a “clean-down (up??) to remove files/settings/libraries included in the application package that are ALSO updated by Microsoft.
Why is this so important? Here is an example: Bloomberg:
The Bloomberg package is enormous, has integration points to Microsoft Office and has a large testing profile while delivering key “line of business” functionality to many finance and research organisations. The Bloomberg package also includes two core system libraries that are ALSO included within the Windows OS: GDI.DLL and SQLOLEDB.DLL. Both these files have been included in “private” or separate directories within the Bloomberg package.
You can update the target system (with Microsoft Update), but Bloomberg will still use the “private” OLD versions – the versions which have been known to have active, publicly disclosed exploits.
This means that Bloomberg is effectively a “back-door” to your system, due to the package containing these shared, legacy, and compromised versions of key system files.
All the efforts to secure your target systems with the latest updates (and associated testing and deployment activities) has been wasted – for every machine that has Bloomberg installed is in fact an open door to bad actors.
As Jason Smith (Liquidware) states,
Liquidware FlexApp does not handle or patch the operating system itself. It is important to understand that FlexApp is solely focused on application layering and delivery.
During Microsoft Patch Tuesdays, the operating system receives updates, security fixes, and enhancements. These updates are handled separately from Liquidware FlexApp. By keeping the application layer separate from the OS, FlexApp ensures that the applications remain unaffected during the patching process, reducing the risk of conflicts and downtime.
I think that the key message here is separation of the application from the OS. Where there is an “intermingling” or mixing of key OS components, used and included in private application specific installations, there is scope for real security issues.
One of the key deliverables for the Readiness platform was to create an automated platform to download and interrogate Microsoft updates file potential “overlap” update files that are also included in application packages.
Here is a sample of the reports that are generated (automatically) each month for each application.
And here is a more detailed view: