Overall, I am quite chuffed with the changes. They offer increased guidance as businesses implement the Essential Eight to keep pace with (and even get ahead of) the evolving threat landscape. Since we’ve quickened our pace towards making the Essential Eight mandatory for some (and hopefully almost all) organisations, I’m pleased to see many businesses taking this seriously and making the strategies a key part of their future security vision.
Please take some time to read all of my previous articles on the updated Essential Eight Maturity Model; the links are at the bottom of this article.
In this article, I look at the updated Essential Eight Maturity Model regarding one of the strategies that businesses largely ignore until they tackle it head-on.
Some of us use macros, some of us don’t, but there are security implications for using the Microsoft Office productivity suite since macros are a long-standing threat vector. To some degree, we must treat them akin to hacking tools that can be used for good and malicious intent.
Controlling macros is like approaching Application Control. You must restrict both the people and the programs in terms of who can execute what, and regard a macro in the same context as an application.
I must also note that macros are not limited to Microsoft applications; macros are used in a large variety of platforms for just as many reasons, so apply the same principles to macros elsewhere in your organisation.
Let’s get to it, shall we?
Where should you start?
For simplicity, I will abbreviate Microsoft Office Macro Settings to ‘MOMS’ through the rest of this article , provided you bear in mind some macros may not be Microsoft at all, but rather those of a third party. Like my real mom (throw back to my Canadian roots in the spelling there), MOMS are valuable to my working life and often help me when I need assistance. Also, like my real mom, if I went astray by her rules, I ended up in a heap of trouble. Except these days if I step out of line, I’ll be breached instead of grounded. The consequences are more severe, and I can assure you I’d prefer a week of no TV over taking out a corporate network any day! But I digress…
If you use macros, ask yourself who uses them, and why. The odds are you do without realising it, as many documents you process daily have them embedded. Take note of the file types you use all the time, with specific extensions like docm, xlsm, pptm, and the like (Word, Excel, and PowerPoint), the “m” indicates a macro-enabled extension. Many businesses rely on macros to make life easier, but they make life a whole lot more difficult if misused.
To be fair, productivity programs are getting better at securing macros by default and at least asking you if you want to run them, but it’s a choice that shouldn’t be left in the hands of the end-user. Most people are more interested in doing a thing, rather than doing that thing securely. Thankfully, in the Microsoft world, Group Policy Objects (GPOs) allow for control over macros, whether they can run, and who can run them, taking the power of choice away from end-users.
That said, there are ways to secure macros, such as demanding they are signed by a trusted authority (like code signing using a certificate) and using, but also controlling access to, third-party macros from the internet or other entities that send files to you. I get some grumpy people when I advise they insist their partners sign macros. They fear losing business but consider the risk to your own organisation. Is it worth a breach and the bad publicity simply because someone finds it cumbersome or annoying when you asked them to sign a macro? You should also consider signing your macros before sending them to a third party. Fair is fair, after all!
Still, the debate around the best way to secure macros is worth having, but just know you have options. These range from outright banning all macros, to simply defining a few policies and creating some GPOs to support them for acceptable use. For example, if you have an internal team that never has to send or receive a macro but uses them for their internal day to day processing, you can define policies to limit the scope to that group.
The ACSC publishes some great controls in this Essential Eight strategy, so let’s look at what it takes to achieve Maturity Level One (ML1) in Configuring Macros. Just as a side note, there is a lot to take in about configuring macros compared to the original Essential Eight advice. ML1 has increased from two to four controls, Maturity Level Two (ML2) doubled from three to six controls, and Maturity Level Three (ML3) more than tripled from three controls to ten! While a jump from eight controls to twenty can intimidate, you’ll quickly realise how the controls are shared and linked between maturity levels (ML).
The previous Maturity Level One consisted of two controls, allowing macros to execute after prompting the user and removing the ability for users to make changes to macro security settings. Pretty basic, right? Thankfully, the new Maturity Level One is much more granular and takes a more holistic approach.
“Microsoft Office macros are disabled for users that do not have a demonstrated business requirement.”
I especially like this control because it says, in black and white, “if you don’t need it, you don’t get it.” I think least privilege is the way to adequately secure many systems, and with a few GPOs in your Active Directory, you can define the required privileges. Then sit back and wait for the hordes of unwashed masses to flood into your office demanding answers. When it comes to revoking and granting privileges, be sure to document the process and have it approved by the executives to give it clout.
“Microsoft Office macros in files originating from the internet are blocked.”
Common sense. And yet we can all agree that this type of sense is not “common” these days. The only reasonable exception is enforcing a policy to dictate all macros must be signed by a trusted third party. And even then, there must be a clearly defined vetting process to ensure that Trojans haven’t snuck in via their wooden horse disguised as a docm file.
“Microsoft Office macro antivirus scanning is enabled.”
Following on from my previous point, scanning macros with your endpoint protection platform is just good practice. Also, scan for more than just macros because the hoodies that inhabit dimly lit rooms are cagey and don’t rely on viruses alone. That’s old school 90’s thinking.
“Microsoft Office macro security settings cannot be changed by users.”
It baffles me why we create policies that can be undone by the very people they intend to protect. It’s like putting a fireproof door on a staircase and someone deciding to cut a hole in it for aesthetic reasons. When you put controls in place for macros, be 100% sure that only your trusted administrators have the power to change them.
ML2 builds on the momentum of ML1 by re-using the same four controls but adding two more for specific connections, and more importantly, system monitoring via logging. Where the controls are the same, I’ll simply copy and paste my above statements, we’ve condensed these sections for your convenience .
“Microsoft Office macros are disabled for users that do not have a demonstrated business requirement.”
(As above, ML1) I especially like this control because it says, in black and white, “if you don’t need it, you don’t get it.” I think least privilege is the way to adequately secure many systems, and with a few GPOs in your Active Directory, you can define the required privileges. Then sit back and wait for the hordes of unwashed masses to flood into your office demanding answers. When it comes to revoking and granting privileges, be sure to document the process and have it approved by the executives to give it clout.
“Microsoft Office macros in files originating from the internet are blocked.”
(As above, ML1) Common sense. And yet we can all agree that this type of sense is not “common” these days. The only reasonable exception is enforcing a policy to dictate all macros must be signed by a trusted third party. And even then, there must be a clearly defined vetting process to ensure that Trojans haven’t snuck in via their wooden horse disguised as a docm file.
“Microsoft Office macro antivirus scanning is enabled.”
(As above, ML1) Following on from my previous point, scanning macros with your endpoint protection platform is just good practice. Also, scan for more than just macros because the hoodies that inhabit dimly lit rooms are cagey and don’t rely on viruses alone. That’s old school 90’s thinking.
“Microsoft Office macro security settings cannot be changed by users.”
(As above, ML1) It baffles me why we create policies that can be undone by the very people they intend to protect. It’s like putting a fireproof door on a staircase and someone deciding to cut a hole in it for aesthetic reasons. When you put controls in place for macros, be 100% sure that only your trusted administrators have the power to change them.
“Microsoft Office macros are blocked from making Win32 API calls.”
This control is the first of two controls unique to ML2 and permits taking your macro security settings a little further.
What is a ‘Win32 API’ call? Glad you asked! The name we call ascertains it is Microsoft Windows 32-bit based, and an ‘Application Programming Interface’ or a way for two programs to interact. For example, I often set up Vulnerability Management solutions that link to an automated patching solution via a (drum roll…) API! Allowing a Macro to make API calls is a Pandora’s Box you don’t want to open, unless you’re ready for the consequences and can control the outcomes.
Like many other elements of application security, if you don’t need it, don’t allow it. These controls are called ‘Attack Surface Reduction Rules’ and are worth looking into in the Microsoft world. To cut a long story short, you want to prevent Macros from connecting to other programs unless you can completely control the transactions. Downloading a macro for free that links to a piece of dormant malware and bricks your computer is all too easy.
“Allowed and blocked Microsoft Office macro executions are logged.”
I strongly encourage logging to be enabled anywhere there is a security implication. While logging ‘blocked’ executions is motherhood, logging the successful ones is more likely to discover and track unauthorised activity. This situation is also a perfect case for engaging a Managed SOC provider to look after the logs. They should offer a wealth of playbooks and responses to macro-related activities in your environment.
Maturity Level Three builds further on ML1 and ML2 by leveraging many of the same controls while adding more to increase granular control over macros in your infrastructure. What is great about the updated Maturity Model is how implementing controls at the lower levels already ‘check the box’ when moving through to the higher levels, saving a ton of time and creating a foundation to build on.
“Microsoft Office macros are disabled for users that do not have a demonstrated business requirement.”
(As above, ML1) I especially like this control because it says, in black and white, “if you don’t need it, you don’t get it.” I think least privilege is the way to adequately secure many systems, and with a few GPOs in your Active Directory, you can define the required privileges. Then sit back and wait for the hordes of unwashed masses to flood into your office demanding answers. When it comes to revoking and granting privileges, be sure to document the process and have it approved by the executives to give it clout.
“Microsoft Office macros in files originating from the internet are blocked.”
(As above, ML1) Common sense. And yet we can all agree that this type of sense is not “common” these days. The only reasonable exception is enforcing a policy to dictate all macros must be signed by a trusted third party. And even then, there must be a clearly defined vetting process to ensure that Trojans haven’t snuck in via their wooden horse disguised as a docm file.
“Microsoft Office macro antivirus scanning is enabled.”
(As above, ML1) Following on from my previous point, scanning macros with your endpoint protection platform is just good practice. Also, scan for more than just macros because the hoodies that inhabit dimly lit rooms are cagey and don’t rely on viruses alone. That’s old school 90’s thinking.
“Microsoft Office macro security settings cannot be changed by users.”
(As above, ML1) It baffles me why we create policies that can be undone by the very people they intend to protect. It’s like putting a fireproof door on a staircase and someone deciding to cut a hole in it for aesthetic reasons. When you put controls in place for macros, be 100% sure that only your trusted administrators have the power to change them.
“Microsoft Office macros are blocked from making Win32 API calls.”
(As above, ML2) This control is the first of two controls unique to ML2 and permits taking your macro security settings a little further.
What is a ‘Win32 API’ call? Glad you asked! The name we call ascertains it is Microsoft Windows 32-bit based, and an ‘Application Programming Interface’ or a way for two programs to interact. For example, I often set up Vulnerability Management solutions that link to an automated patching solution via a (drum roll…) API! Allowing a Macro to make API calls is a Pandora’s Box you don’t want to open, unless you’re ready for the consequences and can control the outcomes.
Like many other elements of application security, if you don’t need it, don’t allow it. These controls are called ‘Attack Surface Reduction Rules’ and are worth looking into in the Microsoft world. To cut a long story short, you want to prevent Macros from connecting to other programs unless you can completely control the transactions. Downloading a macro for free that links to a piece of dormant malware and bricks your computer is all too easy.
“Allowed and blocked Microsoft Office macro executions are logged.”
(As above, ML2) I strongly encourage logging to be enabled anywhere there is a security implication. While logging ‘blocked’ executions is motherhood, logging the successful ones is more likely to discover and track unauthorised activity. This situation is also a perfect case for engaging a Managed SOC provider to look after the logs. They should offer a wealth of playbooks and responses to macro-related activities in your environment.
“Only Microsoft Office macros running from within a sandboxed environment, a Trusted Location or that are digitally signed by a trusted publisher are allowed to execute.”
When looking at security incidents, a common go-to my industry peers use is Assess — Contain — Remediate. This control focuses on containment, and I agree as it’s probably the more valuable phase; containment mitigates what damage can be caused by malicious software. The three containment methods are slightly different but add a layer of protection we should consider beyond just macros.
First, a sandboxed environment permits the macro to ‘run wild’ without fear of impacting or corrupting surrounding systems. Sandboxing has long been used to verify files and programs before permitting their entry, and gets a lot of play around email and web browsing. Think of it like the padded cell.
Second, a trusted location is defined as a safe place where only trusted applications and macros are kept, so we can trust them when we call upon them. It’s like the data centre in a former workplace where once we vetted and classified systems, they were put to work, separate from the test & development centre (TDC) a floor below. In the TDC, we operated more like a sandbox separate from the rest of the network. It was the “trusted location” where the good kids could come and play in the data centre.
Finally, digitally signed is another step where the macro exists in the network but has been signed off by a trusted certificate as valid. Only those systems that trust the certificate will permit execution. It’s like getting a stamp on your hand at the nightclub to get inside, but the bartender gets you to put your hand under a blacklight to verify you can be there before serving you.
Are any of these three methods perfect? No, but they tip the scales in your favour of staying safe and adequately secure should you choose to allow macros in your environment.
“Only privileged users responsible for validating that Microsoft Office macros are free of malicious code can write to and modify content within Trusted Locations.”
In the last control, we defined what trusted locations are, who can deem them ‘trusted’, who can sign-off on trusted certificates and who can access trusted locations.
The operative keywords in this next control are “write” and “modify”, which means any authorised user can read or access the macros, while only those with privileged accounts can move, add, or change the contents.
When we consider threat actors as Malicious Outsiders, Malicious Insiders, and Well-Intended Insiders, this should be adequate to mitigate threats from two of the three. Unless, of course, the insiders have privileged access. This is a perfect example of why you can’t use these controls in isolation; the Maturity Model is built to be complementary.
“Microsoft Office macros digitally signed by an untrusted publisher cannot be enabled via the Message Bar or Backstage View.”
Now, just because a macro is signed doesn’t mean it’s always trusted; those doing the signing may be untrusted, not the macro. Anyone can stand up a Microsoft Certificate Authority (CA) on a server platform and start issuing certificates, including those used to sign macros and other code. The Root Certificate and CA must be published and trusted by those who will access the signed macros. Securing the Public Key Infrastructure (PKI) of your environment is crucial, or else policies surrounding digital signing and trusted certificates fall apart.
“Microsoft Office’s list of trusted publishers is validated on an annual or more frequent basis.”
You would be shocked at the sheer number of environments I see that have not made changes to their trusted publishers for certificates and certificate authorities, so I would be equally sceptical on the cadence of MOMS reviews. As with anything security-related, it must be reviewed, validated, and signed off regularly.
Annual reviews happen to be a solid benchmark, but I would advocate for mini reviews every quarter or half, especially after significant changes or upgrades to your environment. Make it a part of your annual security assessments as a minimum and be sure to execute when the time comes.
“Allowed and blocked Microsoft Office macro executions are centrally logged and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cybersecurity events are detected.”
In ML2, we looked at logging, so in ML3, we take it a step further. In ML2, we talk about logging failures and successes. Here, we look at central logging (think of a SIEM or, better still, a Managed SOC), which you should be doing anyway. Beyond that for stage three maturity, we also log moves, adds, changes of macros, implement monitoring around Indicators of Compromise (IoC) and delve into the world of Security Orchestration, Automation, and Response (SOAR) to take action when an event is identified.
Sound like a lot? It sure is! No doubt you have many questions, but just take one step at a time. We’re not trying to “boil the ocean” to use a tired cliché, but rather secure your environment. Therefore, I advocate for a Managed SOC because they can do all the above with ease, for a fee, while you focus on running the business instead of perfecting your insomnia. If you’re interested in learning more about Security Operation Centres (SOCs), take a read of one of my other blogs , or reach out to the team anytime to start a conversation.
Stay safe out there.
Using the ACSC recommendations as a framework, Data#3 has built an Essential Eight Assessment to help organisations understand and improve their security posture.
The Essential Eight Assessment is a 5-day engagement, conducted by a Data#3 Information Assurance Specialist, including up to 2 days spent onsite with the customer.
This is blog 4 of a 9-part series. See earlier posts on:
1. Your guide to the ACSC’s Essential Eight Maturity Model
2. Essential Eight Maturity Model: Application Control
3. Essential Eight Maturity Model: Patch Applications
4. You are here.
5. Essential Eight Maturity Model: User Application Hardening
6. Essential Eight Maturity Model: Restrict Administrative Privileges
7. Essential Eight Maturity Model: Patch Operating Systems
8. Essential Eight Maturity Model: Multi-Factor Authentication
9. Essential Eight Maturity Model: Regular Backups
