Symantec Management Platform (Notification Server)

Currently running NS 7 with Patch Management add on. We are using Altiris only for patching our server platform (many thousands of servers), and have reached a point we need to get our servers in the DMZ installed. Working on a document for our Information Security department to authorize putting a site server in a vault that has access to all of our DMZs.

I have the port information I need, however InfoSec is questioning the client security of Altiris, and I haven't been able to find any good articles to explain how clients agents are secured. Their main concern are things like spoofing attacks, and the like trying to break through my vault firewall and then getting access to the rest of our server farm. Does anyone have detailed information they could link me to?

is 32bit based, and doesn't have any physical security itself (password lockdown, hashing,etc). It runs (typically) with the local system account (Microsoft), so cracking that would be tough in itself. The client communicates typically via http but can be done via https as well.

There is a good article here (by Screenbert) on how to secure agents via AD Group Policy, but I'm not sure this would apply to servers in the DMZ.

You may consider a whitelisting approach, Savant makes a good product that integrates with Altiris, but again, how useful this would be to servers in a DMZ, I can't say.

But the agent doesn't have any way of ensuring to the NS or site server that the client is who it says it is? I know it uses a GUID, but is that sent cleartext or is there any mechnism to secure itself from a man in the middle sniffer using that information and pretending to be the client?

I think that's where you would use SSL to secure the communications.  All client-server communication would be encrypted.

Does the InfoSec team have concerns that aren't addressed by using SSL?

You could create a report to check for duplicate GUIDs.  Any system pretending to be the client would have to use the same GUID as the client, and at least in that scenario you would know it has the same GUID (stolen) as another system (legitimate).  However, I can't see how someone would obtain this information if you use SSL.

Also...say someone managed to join a rogue computer to your NS infrastructure.  What exactly are they going to accomplish?  Posting inventory?  downloading the inventory package, or some software packages?  I suppose if there was some SMP vulnerability where it improperly parsed inventory data...but that would be fairly unlikely, and you would still have AV running on the NS and scanning any incoming inventory data before it is parsed (so even if there was some XML exploit that could be exploited, you would still have scanned the .nse files in \\server\nscap\evtq* folders (but be sure to exclude the \Process subfolder; that can kill your performance and lead to thousands of .nse files stalled in the Process folders, especially in EvtQFast).

All you need to open to the DMZ is one port (we used a random port < 1024 as our default and added it to IIS as the default port, but with 80 as a backup for easier internal access).  All Console access is authenticated by AD group membership, so it is not likely that someone could remotely access your NS console.  The increased reliance on Task server makes things a bit more complex, but I think even in that case you could control it fairly tightly.

I'm not an Info Security expert by any means...but I just don't see any "real" vulnerabilities.