Moving away from macros in documents

Macros are little pieces of software included within a document to automate certain tasks.

Macros are not a good way to meet user needs

It might be convenient to make use of macros within your own documents on your own computer. However, it no longer fits within a modern security framework to send documents containing software to other people.

Macros are extremely powerful and are easy to abuse. Getting an unsuspecting user to activate a malicious macro in a document is the first easy step to compromising an entire organisation in a targeted attack.

Running unknown and unvalidated software embedded inside a document received by mail or downloaded from the web can mean turning your computer over to a remote attacker or a botnet with a single click. Even if you know and trust the sender, he or she may have fallen prey to a similar attack before you.

The UK Government advises against their use in documents and does not allow them to be included in documents that are shared publicly.

Migrating away from macros

If possible, see if your organisation can disable document embedded macros altogether. Block these both at the application level by default and preferably scan for them inside incoming documents and remove them before they reach the user. There are better, more convenient and more secure alternatives to achieve the required goals than using a volatile hybrid of document and software.

If you're currently using a macro in a document, the first question you should ask is do you really need an office format to meet the user need? An office suite environment may not be the most suitable tool. A web based solution is often preferable in most cases where interaction is needed.

Using extensions

If the office application is the right choice to meet the need, you have a number of alternatives available to reach the desired functionality. Many office applications offer some sort of extensibility mechanism, like add-ons, extensions or plug-ins. This makes it possible to share custom software functionality with others separate from the regular content workflow.

You should be cautious if you consider doing this. Custom software functionality can result in interoperability problems. This may affect usability and lead you to become locked into a particular application or become tied to costly specialist support.

You should test any add-ons, extensions or plug-ins for interoperability and usability to make sure there are no unintended side effects when you share documents across platforms. They should also be vetted by IT security professionals.

If you separate the developer or system administrator level access from the content level access, at which normal users work, you can have a much simpler security policy and more fine-grained control.

Don't bother too much with legacy

Ask your users to report what functionality they would be missing out on if document macros are disabled.

You may discover high numbers of macros are being used if you run an automated scan on a system drive . Many of these will be undocumented, quick and dirty hacks by a user to get something done. Some will have been used only once, or will no longer be in active use. Others are just copies of the same over and over again. Recreating most of these macros as a plugin would not be worth the cost.

Tip: Just ask your users to come forward with what they actually use. One German government agency that made the switch to ODF some years ago indicated that they experienced a dramatic difference between the automated macro count and the amount of macros their users actually wanted back after the migration: they went from an estimated 9000 macros on disk to nine macros that needed to be ported to the new situation. After that, macros were no longer considered an issue. Probably, your case will not be much different.

Getting rid of macros is something that you need to do independent of switching to ODF (in fact regardless of the document format you use). Your migration to open file formats (and in some cases a switch to new applications) is however a good time to take stock and clean up your existing processes. It will help your organisation and your users data to be more secure. If possible, start working on solving the macro issue as soon as you can. It also helps to not have to do everything as a _big bang _change. If something going wrong, your users might get confused what is causing the issue.

You can determine a roadmap and allocate a budget for turning off document embedded macros once you have a good overview of the functionality that needs to be recreated at the plug-in or application level. You should involve your IT security team to make sure you understand any security implications. For most functionality there will be readily made extensions, add-ons or plug-ins that provide the features you need. If not, you can get these built as long as they don't damage interoperability or usability across other platforms

Invest in reducing friction

Migrating to an application independent file format has the additional benefit of uncovering unknown and undesired dependencies on application features as well as invisible dependencies and unmanaged activities within your organisation. Reducing the dependency your organisation has on current applications will pay for itself in a smoother and faster transition.

In some cases you may still receive documents which contain macros. This should not get in the way of you securing your organisation as soon as possible.

If, for a time, you have no other way to work with these documents, consider providing a standalone machine where users can open documents with macros.

You can point to this guidance to inform people who send you documents with macros to let them know why you are no longer accepting them.