Application control without breaking the finance team

Of the eight mitigation strategies, application control is the one that most reliably appears on a roadmap, moves quarter to quarter, and is still there two years later. It is not because the technology is hard. Windows has shipped the capability for years and the third-party market is mature.

It stalls because it is the only strategy in the set whose failure mode is immediate, visible and attributable. Patching badly is a slow problem. Application control badly is a phone call from the CFO at four o'clock on the last day of BAS.

What application control actually asks for

The concept is inversion. Antivirus and EDR work from a list of things that are known or suspected to be bad and allow everything else. Application control works from a list of things known to be good and blocks everything else — executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets.

That inversion is why it earns its place. It does not need to recognise the malware. A brand new ransomware binary with no signature anywhere in the world does not run, because it is not on the list, and neither is the script that would have downloaded it.

Broadly, the ASD maturity model escalates it like this — check the current published model for the exact wording, because it is revised:

• Maturity Level One — on workstations, restricting execution from user profile directories and the temporary folders used by the operating system, browsers and email clients. That is deliberately targeted: those are the locations an email attachment or a drive-by download lands in.
• Maturity Level Two — extended to all locations on workstations and to internet-facing servers, with Microsoft's recommended application blocklist applied and allowed and blocked execution events centrally logged.
• Maturity Level Three — extended to non-internet-facing servers, with driver control and Microsoft's vulnerable driver blocklist, and rulesets validated on a defined cycle.

Worth knowing before you plan a two-year programme around it: ASD has signalled that the Essential Eight will be retired and replaced by a multi-chapter Essentials series. The control itself is not going anywhere — allowlisting is not a fashion — but the labels around it will change. We wrote about what that transition means separately.

Why finance is where it breaks

Every organisation has one team whose software estate does not look like the standard operating environment. Usually it is finance, and often it is finance and one other — the engineers, the practice managers, the people who run the plant.

The pattern is consistent. Finance runs software that is older than the rest of the estate and cannot be replaced casually because the data and the workflow are load-bearing. It runs Excel with add-ins, some of which are XLL or COM components that behave exactly like the thing you are trying to block. It runs utilities that came from the bank, the accountant or the ATO. It runs one-off installers that arrive by email from an auditor in the week they are needed and never again. And a lot of that software self-updates by writing a new executable into a user-writable directory, which is precisely the behaviour application control exists to stop.

None of that is unreasonable behaviour by the finance team. It is the shape of the work. The mistake is discovering it during enforcement rather than before it.

Audit mode, for a full business cycle

Every application control product can run in an audit or monitor mode that logs what would have been blocked without blocking it. Everyone knows to do this. The part people get wrong is how long.

Two weeks of audit data is not a picture of your organisation. It is a picture of one fortnight. Finance in particular runs on a calendar: month-end close, quarter-end, BAS, payroll year-end, EOFY, the audit. Software that only executes in July does not appear in a March sample, and the first time you will meet it is the day it is blocked, in the week it matters most.

Run audit mode across a full business cycle. For most organisations that means a year, and if a year is not acceptable to the people funding the project, at minimum span the quarter-end and one statutory deadline. Then review the audit log with the team, not just with IT — a line item reading updater.exe in a temp folder means nothing to a systems administrator and is instantly recognisable to the person who uses it every day.

Publisher rules, not path rules

How you write the ruleset determines whether it survives contact with normal operations. There are three common approaches and they are not equivalent.

• Publisher rules allow software signed by a particular vendor's code signing certificate. These are the ones to build on. The application updates, the signature is still valid, nothing breaks, and you have not widened the rule to cover anything else.
• Hash rules allow one exact binary. They are precise and they are brittle: every update invalidates the hash, which converts your ruleset into a maintenance task that grows with your software estate. Reserve them for unsigned software you genuinely cannot replace.
• Path rules allow anything in a location. These are the dangerous ones. A path rule over a user-writable directory undoes the control entirely — you have told the system to permit execution from exactly the place an attacker can write to. If a vendor's software forces you toward one, that is a fact worth raising with the vendor, and worth recording as an accepted risk if you proceed.

The same logic applies to exclusions by group. Exempting the whole finance team is an appealing shortcut on a difficult afternoon, and it leaves you with application control everywhere except the department that receives the invoices, holds the banking credentials, and is the specific target of email compromise. If an exception is genuinely needed, scope it to an application, not to a person or a team.

The exception path is the whole project

Here is the thing that decides whether application control is still enforced in eighteen months, and it is not a technical control at all.

When someone is blocked, what happens next? If the answer is "raise a ticket and wait for the standard queue", the control will be switched off. Not immediately — but the first time a genuine block lands on a genuine deadline and there is no route to resolution within the hour, somebody senior will instruct somebody junior to disable it, and it will not be turned back on.

Three things need to exist before you enforce:

• A named owner who can approve a new application, with a delegate for when they are on leave.
• A same-business-day path for urgent requests, with an agreed definition of urgent. This is a service level, and it should be written down.
• A block message that tells the user what to do rather than a generic error. Most products let you customise this. A message naming the service desk and the request process turns a support call into a process step.

Approving fast does not mean approving carelessly. It means the decision — this vendor, this signature, is it legitimate — is made by someone with the standing to make it, in a timeframe that does not force anyone to route around the control.

Enforce in rings, finance last

Move from audit to enforcement in stages, and let each stage prove the exception process before it carries real weight.

• Ring one: IT. The people who can diagnose their own blocks, and who should experience the control they are asking everyone else to accept.
• Ring two: a department with a predictable software estate and a manager who is willing to be an early adopter. Enforce the targeted Maturity Level One scope first — user profiles and temporary directories — rather than everything at once.
• Ring three: the rest of the organisation.
• Ring four: finance and any other specialist team, with their audit data reviewed line by line beforehand, and deliberately not during a close period.

Have a documented rollback for each ring. Knowing you can return a group to audit mode in minutes is what lets you enforce with confidence instead of postponing again.

Keeping a ruleset alive

A ruleset is not a project deliverable, it is a standing obligation. New software has to come through the same gate, or the exception list quietly becomes the real policy. Review it on a cycle and remove rules for software nobody runs any more, because every stale rule is permission you are still granting.

Keep the blocked-execution log where somebody actually looks at it, too. It is not only an operational feed. A cluster of blocks for something nobody recognises, on a machine that should not be running installers, is a detection — and it arrives with the name of the user and the path it came from already attached.

Questions