Servers are critical assets. Endpoints are critical entry points

Application control belongs on servers and on endpoints. That part is not usually argued about. What gets missed is that the risk it addresses is not the same in each place, and a policy designed for one is a poor fit for the other.

The difference is not how much the asset is worth. It is where the attacker has to be before the control matters.

Servers are reached. Endpoints are where it starts #

A server usually sits behind something. To reach it an attacker has to exploit a public facing service, steal a credential, come through remote access, or move across from somewhere else they already hold. Network segmentation, restricted administration, privileged access controls and monitoring all sit in the way.

An endpoint is not behind those things in the same way. It is the surface the organisation presents to the outside world every day, by design. People open email, browse, download, share files, join meetings and connect from networks nobody controls.

That is the whole distinction, and it is worth stating plainly.

Servers are usually reached after a path exists. Endpoints are usually where the path begins.

Why endpoints are exposed differently #

The exposure is not carelessness. It is the job.

Email attachments, browser downloads, file sharing, collaboration platforms, documents that carry macros, scripts, meeting links, removable media, developer tooling, third party support tools, and software people genuinely need. Every one of those is a normal business flow, and every one is a way for a file to arrive.

You cannot remove them. What you can decide is whether an arriving file is permitted to execute.

That is why application control has such a strong preventive effect on endpoints. It does not stop the file arriving. It stops delivery turning into execution, which is the step everything else in the intrusion depends on.

Why servers are a different problem #

Servers should be boring, and that is their advantage.

A server is not expected to browse the web, open attachments or run whatever somebody downloaded. It runs approved services, agents, libraries, scripts and administrative tools, and the set changes through a release process rather than through a person deciding they need something. That predictability makes a strict allow list far easier to sustain on a server than anywhere else.

The consequence side is the reverse. Servers host identity services, databases, business applications, file shares, backups, management systems and often the security tooling itself. Unauthorised code running there is a much bigger event than the same code on a laptop.

So the shape is lower likelihood of arrival, higher consequence of execution, and a software set that is genuinely controllable. That combination argues for the strictest policy you run.

Two objectives, not one #

Written down, the two policies are aimed at different outcomes.

On endpoints, the objective is to stop untrusted code becoming the first execution. The attention goes to the places files land and run from. User writable locations, temporary folders, browser and email download paths, scripts and installers, and anything unsigned or unrecognised.

On servers, the objective is to keep the workload intact. The attention goes to what the workload legitimately needs, and to keeping that set honest through change control, revalidation after patching, and monitoring what gets refused.

Both are application control. They are not the same deployment.

Why endpoints often deserve to go first #

The usual instinct is to protect the most valuable thing first, so servers get prioritised. That is sound on asset value and weaker on attack path.

Most intrusions that end on a server did not start there. They started with a person, on a device, doing something ordinary. Reconnaissance, credential theft and lateral movement all happen after something ran on that device.

If code cannot execute on the endpoint, the attacker does not get the foothold that the rest of it depends on. Protecting the endpoint is partly how you protect the server.

None of which is an argument for leaving servers until later. It is an argument against assuming value alone sets the order.

What this means for how you scope policy #

Three things follow.

Do not build one policy and apply it twice. A policy tuned to a server's predictability will block real work on endpoints, and a policy loose enough for endpoints permits far more than a workload needs. That is one policy design failing at two jobs. One policy estate, a profile per business unit covers how to hold several profiles without ending up with several estates.

Expect the operational cost to sit in different places. On endpoints it is software diversity and the volume of requests. On servers it is availability and change risk, where the fear is not a blocked request but a blocked service at two in the morning.

Judge readiness separately. Servers and endpoints will not reach enforcement at the same time, and there is no reason they should. Audit mode to enforcement covers what audit does and does not tell you before you commit either of them.

Application control is the same Windows control in both places. The risk it is answering is not, and the policy should say so.

PoliEze exists to make that practical, so one estate can run different policy profiles for servers and endpoints without becoming two programmes. The platform covers the rest.

Sources #

• Application control, Australian Signals Directorate
• Initial access, MITRE ATT&CK, for phishing, external remote services and exploitation of public facing applications
• Application Control for Windows, Microsoft