I saw an article today whose headline ("Remember macro viruses? Infected Word and Excel files? They're back...") drew my eye. It also got coverage on The Register in their usual style :-).
The gist is that virus-infected Macros fell out of fashion due to security changes in Office, but now the target is the User rather than Office. The aim is to persuade the User that the document is more secure because the macro is present and to just click to enable the content.
The article (and the comments that follow) are mostly about random documents sent to you from somewhere out there on the Internet. Clicking to open those (let alone to enable macros) is rarely a good idea.
Inside an Enterprise, macros are used more frequently than the article needs to acknowledge. They're used to add extra automation functionality to Word and Excel. In this case, the macro-enabled document is often from a known colleague and the enterprise web domain from whence it came is a trusted zone.
Typically, a layered security model would be used inside an enterprise to defend against this threat.
The first perimeter layer should be mail scanning - do you really need macro-enabled documents coming in? If not, block them from inbound mail.
The next layer should be that all the client PCs are up-to-date with anti-virus signatures. Check that your enterprise anti-virus solution is scanning Office documents. This catches cases where a document has come in from a USB stick or a file sharing service like DropBox.
Application level filtering such as setting the macro security to "Disable all macros except digitally signed macros" provides a final layer, but it has the disadvantage that signing isn't well understood.
A way to improve security (not mentioned in the article) for behind-the-firewall macro-enabled usage is to generate and use a self-signed SSL security certificate. These are not so suitable for public websites, but are useful for internal sites and applications such as code signing (to confirm the software author and guarantee the code has not been altered). This is especially true if the organisation is large and there's a chance the colleague sending the file is not known to the recipient.
Self-signed certificates can be created for free using a tool such as the OpenSSL toolkit, which can be used to generate an RSA Private Key and CSR (Certificate Signing Request) for Linux/Apache environments. In a Windows based environment, you can use a tool such as SelfCert.exe, or generate a code signing certificate using Microsoft Certificate Services.
In some implementations the end-user will still get a warning and have to accept the certificate. Some argue this can promote bad habits if end-users become blasé about accepting SSL certificates because "they were told to". However, in the internal enterprise model we are addressing, the way around this is to pre-install the SSL certificate on every machine. That way, the trust question is never asked. A means to achieve this is for IT departments to push the certificate out as a trusted publisher to client PCs using group policies. Read this Microsoft TechNet article for more detail.