Quoting Juice

Gert asks: When using SVS, it is possible that a file being replaced by a Windows security update might actually exist in more than one place - in the base and also in one or more application layers. What happens? How do I ensure that the machine gets updated correctly?

A:
If you have intentionally included a system file inside a VSP, to ensure correct application functionality, you do introduce a security complexity. Two versions of a DLL (one in the base and one in an application layer) means that Windows Update will only see and replace the one in the base. This potentially leaves an older version with a known vulnerability in service and loading into memory.

[This is a similar problem as with COM redirection, btw, an older technique that many people used to ensure apps got the right version of system files.]

The competition thinks this is a good thing, and touts it as part of their value proposition. See this. (That text has been toned down since SoftGrid became a Microsoft product; after all, no one knows better than MS the implications of selecting convenience over security.) Altiris, however, doesn't believe it is optimal to, by default, not update system files that are in VSP's. We view this as a limitation, a problem that must be solved in a future release. Management products should default in favor of security, and give customers the flexibility to change that behavior only when they make the conscious decision to do so.

Regardless, Virtual Patch doesn't exist yet, and for today we behave like the other guys (in this regard, at least). So let me provide some guidance on how to keep things working, manageable and secure with SVS 2.x.

1) As far as Altiris products go, the answer is the Wise Risk Assessment tool (a component of Wise Package Studio). Whether you are using SVS, COM redirection, or any anything else that can possibly result in system files being in "other than the normal" locations, this tool tells you about it.

2) As a best practice, just because SVS enables you to put multiple copies of an object (file or reg value) on a box doesn't mean you always should. Another thing Wise Package Studio brings to the table is its Software Repository. This is a master catalog of all of the applications in your environment, and all of their components and dependencies. Using this data, WPS can help you identify duplications across packages so you can decide when they are really necessary.

3) The exclusion list included with Wise Package Studio can help prevent the accidental inclusion of OS specific files from getting into your VSP's. To take advantage of the exclusion list, use Wise Package Studio to setup capture your VSP's, double checking the results of the capture in the Inclusions / Exclusion dialog boxes after the final machine scan. (If you still want to use the SVSAdmin tool to capture, running the 'Post capture Exclusion List Processing' feature in WPS 7 will clean the VSP's after they have been imported into the database.)

4) Put security audit scan agents on the Ignore Process list. This will allow SecurityExpressions (when doing an agent-based scan), or whatever audit tool you use, to see the SVS redirect areas at the real locations, rather than their virtualized locations, allowing every version of an object to be seen. (Alternately, you can use the svscmd exec option in scripting to recursively scan all layers and get the virtualized locations.)

In preparing this FAQ, we also gathered a few other good tips from the Wise and security teams. A feature article is in order, I think, or at least a security section of a bigger best practices article. We'll get on it, Gert! Thanks for bringing up this important issue!

The original is here.