My two biggest focal areas regarding security are: intrusion analysis and secure software programming. After testing two different, but related, security products (SEP 11 and Policy Orchestrator) and then performing the subsequent installations of each, I have come to the conclusion that:
Software installers should automatically verify known registry/GPO settings as necessary, or should at least return the top [five] possible failure mechanisms. I know I am not the first to suggest this requirement. I am also aware that there are some concerns with allowing an installer TOO much access to high-value information on the system. However, I believe that there is a compromise to be had somewhere in the middle.
Of the two products, McAfee's ePolicy Orchestrator (ePO) is used, at least in this instance, for compliance monitoring. It does have some other excellent functionality, and the program is good in general. However, I am not making a sales pitch.
The biggest issues with ePO is that the following settings MUST be made:
- Log on as a service: the accounts listed here must include the account used by ePO. This is somewhat of an obvious requirement. However, an overzealous SysAdmin can cause some heartache for the one installing ePO (as was the case here), as this requirement isn't noticed until half-way through the process.
- NtfsDisable8dot3NameCreation: In general terms, allowing for 8.3 names presents a low risk to the system and can slow down high-use systems. However, it should be noted that "turning on" this setting is an FDCC requirement. The problem with this setting being enabled is that Apache, used by ePO, will not install correctly, or if enable later, will not load properly (roughly 100 core load error messages will display on the initial GUI under the log in section).
The other product, the one that inspired this rant, is Symantec's SEP 11. While this product appears to be an improvement in many ways over version 10, there are still some kinks to work out. However, I believe some of these "kinks" could be mitigated, or at least avoided, if some functionality was tested by the installer, specifically LDAP authentication. Buried in a Symantec Forum was the fact that if:
- LDAP Server Signing Requirements must not be required. If this setting is "required," the SEP Manager will NEVER authenticate to the LDAP. Troubleshooting this issue was easier with Wireshark captures than with searching Symantec (or maybe I just felt like being an uber-geek that day). What I decided to do was to start capturing through Wireshark, with a simple filter set for my source ip address. Once I did that and attempted a couple of authentications, it was obvious that the LDAP server was immediately denying the authentication attempt. This was obvious from the fact that the LDAP server was immediately issuing a RST packet after the Hello packet. With this setting changed, the SEPM could easily import from the LDAP server.
So my conclusions are these:
1) Although documented in both cases above, some of the documentation was "bulky" or timely to locate. A better organization of "known issues" in release documentation would be helpful.
2) If the installer called a method to verify these settings, or attempted to "use" these settings during install, and then returned the appropriate error message(s), troubleshooting would be less time-consuming (read: more cost effective).
3) It is still better to look at what the program is actually trying to do on the network, then sift through pages of help forums. (I should add that, although not suprised, tech support at one of these companies, was not aware of the issue or the fix). I guess I would rather spend time looking at the traffic, reading the packets, and using that to decipher what is happening on the network.
4) The SSLF rearing it's ugly head, again, validates once more that careful testing and understanding of the settings is definitely required.
No comments:
Post a Comment