Don't be the Smelly Kid

Often I find security professionals and management treating security as a project or series of projects. While there may be security related projects within an organization, I would argue security as whole should not be treated as such. Securing ones environment does not have defined start dates, end dates, or even budget. It needs to be part of every information system project and baked in from the beginning. Security should be part of your regular scheduled maintenance and support structure. By treating security as one would treat personal hygiene, security becomes part of the daily routine. Lather, rinse, and repeat.

I have eluded in previous posts that security products, while sometimes helpful, can also cause more overhead and issues. Specifically, products designed to provide a "band aid" to improperly designed or implementation information systems would be the equivalent of splashing some cologne on everyday and not taking a shower. Eventually, there will not be enough cologne in the world to hide the stench. So don't be the smelly kid! Lather, rinse, and repeat.

The Detrimental Effects of Compliance Auditing on the Security of Small Business

Many argue that regulatory compliance with PCI, SOX, MA 201 CMR 17.00, and others help establish the minimum baseline for security in organizations. I think the point may be valid in organizations that initially had little to no security but I would argue that it has the opposite effect on a company that has the basics and beyond covered. To be specific, smaller companies which have one or two security professionals running the gambit from configuring Group Policy to writing Policies and Procedures are often already overwhelmed (note I fit into this category). Such professionals may quickly find themselves concentrating on out dated, incomplete regulations and laws rather than concentrating on reducing the risk of data loss by keeping up with current attack vectors, vulnerabilities, patches, and system logs.

I recently had a discussion with some colleagues on the subject of extending the compliance auditing of SAS providers to include data beyond financial or personal identifiable information. Initially it sounds like a valid and justifiable cause. But what is the end game? If it is mountains of one hundred page SAS70's with no regulation or law behind them, then it might be a worthy cause. But stacks of paper may show nothing about the security of the data being stored by the provider and will certainly distract from other effective methods of reducing risk. Honestly, if I could spend some time shooting the shit with the solution providers security team about current security trends and attack vectors, I would probably have a more accurate assessment of their ability to secure the data.

I am not suggesting we ignore current laws or regulations. We have an obligation to follow them. I am also not suggesting we do not review the hosted solutions outside vendors are providing for non-regulated data. I do believe that the review process should not mimic compliance audits, however. The time spent during the review process should match the amount of risk involved and assurance we achieve from the security review. If the security of such data is absolutely crucial, one might consider not storing the data there in the first place.

Lessons Learned: Vulnerability and Expectations Management

As an information security professional, a large portion of my work day is spent with vulnerability and patch management. So when I saw a security advisory addressing multiple vulnerabilities in both Symantec's Corporate Antivirus and Endpoint Security Solution products last June, I immediately investigated. You can read the security advisory here. I became concerned because other Vendors also use the Intel File Transfer service so I thought it be prudent to investigate.

I began looking around and noted that Tenable Network Solutions had a Nessus plugin. You can find the plugin here. So like any true geek with nothing to do on a Saturday evening, I began scanning. I was surprised at what I found.

The systems running the Intel File Transfer service from other vendors were not vulnerable but systems patched with Symantec 10.1 MR8 were still be vulnerable. The solution table in Symantec’s Advisory states that the issue with AMS2 was fixed in this version.

I contacted someone I knew at Tenable and asked for assistance in verifying the vulnerability. The plugin actually contains remote execution code but it is commented out by default. With instruction from Tenable I uncommented the cmd = "calc"; line in the NASL script and ran a nessusd -R to perform a reload of the Nessus Database. Sure enough, the next scan verified that cmd.exe would execute without authentication on the vulnerable machines.

So what gives? Is Symantec's advisory incorrect? Not entirely, although it may be misleading. This became a case of reading the fine print. Further down the advisory we find this information:

"AMS2 is installed by default with Symantec Antivirus Server 9.0. AMS2 is an optional component in Symantec Antivirus Server 10.0 or 10.1. These vulnerabilities will only impact systems if AMS has been installed."

And further down, under mitigation section:

"Reporting has replaced AMS2 as the recommended method of alerting. Symantec Endpoint Protection Central Quarantine Server 11.0 MR3 and later no longer include AMS2. Symantec recommends that customers who are still using AMS2 switch to Reporting to manage alerts in their environments. If the customer is unable to switch to reporting immediately then Symantec recommends that the customer either disables AMS2 as a temporary mitigation or completely uninstall AMS2."

All the systems vulnerable had all been upgraded from an earlier version of Symantec Antivirus Corporate Edition 9.X. During the remote upgrade process there seemed to be no way to specify if AMS2 was to be installed or not. Symantec support seemed unable to instruct me on how to remove or disable AMS2 from the affected systems and I have spent the last several months trying to get them to change the advisory so that the solution table listed at the top of the document noted this tidbit at the bottom. To say the least I have not been successful in this endeavor and feel a bit frustrated. Although the Sales Executive has been nice enough to try and sell me their Endpoint Protection v11 product and recommended I start with a fresh install.

If you do want to mitigate the vulnerability, I determined disabling the Intel File Transfer service works well and does not seem interfere with my configuration. I recommend you test this in your own environment however.

So Lessons Learned:

Read Security Advisories carefully.
Scanning is an important part of any vulnerability management plan.
Manage your expectations when dealing with vendors.

Updated December 29, 2009

Posted two updates on the release of the POC for this vulnerability and a report of the exploit being used in the wild by SANS ISC.