ASD Essential Eight Explained – Part 5: Disabling Untrusted Microsoft Office Macros

The Essential Eight

The Australian Signals Directorate (ASD) Essential Eight has received considerable attention since it included an additional four strategies to the previously defined ‘Top 4 Strategies to Mitigate Cybersecurity Incidents’. Logan Daley continues the ASD Essential Eight Explained series below.

Disabling Untrusted Microsoft Office Macros

What is it?

Macros are basically a batch of commands and processes all grouped together to make life a little easier when performing routine tasks. In many cases, they simply execute as the user and save untold hours, reducing the number of errors one can make with tedious tasks. Unfortunately, Macros are also a popular exploit through leveraging this autonomy and ability to execute code, reaching even beyond the application itself. Anyone that has been around for a long time will remember the Melissa macro virus and the havoc it caused with email services worldwide. Or even the Wazzu macro virus that altered the content of files. Most of this is due to Visual Basic for Applications (VBA) which is still used to this day. Microsoft, to their full credit, has done a tremendous amount of work to secure macros in the past several versions of Office, but you can’t save people from themselves. I once had a car with advanced safety features but all the technology in the world wouldn’t keep me from driving off the road if I did it on purpose.

Where do I start?

While it might be tempting to simply disable all macros, full stop, that isn’t the answer. Remember that macros exist for a reason and that’s to automate tasks, save time, and keep some of us from going loopy after doing the same thing a thousand times over. A better approach is to selectively trust macros but remove the choice from the end user. How do we trust macros? Digitally sign them and then lock down the application to disable all but the signed ones.

So how do I digitally sign macros?

This is where it can get complex. While there are tutorials about how to self-sign digitally signed macros, self-signed certificates really don’t inspire any trust in the broader community, so the availability of a Public Key Infrastructure (PKI) infrastructure, either internal using the Microsoft solution or external using a third-party trusted Certificate Authority (CA) is preferred. Rather than bog you down in details, I would encourage you to start exploring digital signing of your macros and get the right people involved before moving ahead. This is a perfect example of when you need to put your hand up and ask for some help unless you have the in-house skills. On top of digitally signing and distributing your macros, you also need to consider policies that lock down these features in the office applications lest your users will just go in and disable this protection anyway to run all macros. Yes, scary, I know.

Of course, in an environment that doesn’t need macros, go ahead and just disable them completely. I doubt, however, that many of these environments actually exist.

Any pitfalls?

There can be a lot of moving parts here, so a plan is critical. Consider group policies, restricted privileges, macro control and distribution, digital signing and PKI and you will quickly see how many places you can come off the rails. Please don’t throw this in the “too hard bucket” because there is a lot to gain when macros are managed correctly, especially in an environment where the productivity can be impacted tenfold by their proper use but a hundredfold by their exploitation.

The ghost in the machine?

The macros themselves have to be trusted because as you can imagine, if we make a mistake and then trust that mistake, digital signing won’t make an ounce of difference. You must QA the macros and thoroughly test them before using them. Human error, as with all things, is omnipresent.

How do I make it work?

Determine if you need macros. If no, then happy days, just implement a blanket policy to disable them across the board and move on. For non-domain systems, just disable them in your applications. For the rest of us, and likely the majority, that need macros, it’s time to take inventory of the macros we use. Delete the ones we don’t and begin the process of vetting the ones we do. Digitally sign your required macros after thorough QA and testing, and then distribute and control as needed. Ideally, we should never execute an untrusted macro unless we’re the ones that developed it and are trying to make it legitimate. Once these hurdles have been crossed, you can get back to unhindered productivity and actually make it out of the office before midnight.

Am I missing anything?

By the way, it’s worth considering macros in applications other than office. Microsoft isn’t the only ones that figured out macros are incredibly powerful.

How do I start?

Find out what your current policy is on Microsoft Office Macros and if you don’t have one, consider creating one. As I mentioned earlier, this can be complex with a lot of moving parts so unless you have the resources like in-house skills and PKI, put up your hand and ask us to help you. If you have the resources, look at locking down your macros and controlling their distribution and the end user control over the applications. People are very skilled at Googling how to bypass security settings and pushing their limits. Logging and alerting may be a worthwhile side project to this as well. For those of you that already have all of this in place including digitally signed macros, it’s time to run a health check on your current state to make sure it’s still doing what it’s supposed to. Nothing in this world is even set-and-forget.

Read more from the ASD Essential Eight Explained series.

Go to: Part 1: Application Whitelisting | Part 2: Patching Applications | Part 3: Restricting Administrative Privileges | Part 4:  Patching Operating Systems