A help desk ticket arrives: a user installed a free PDF converter, and now the browser is full of ads and the EDR is raising alerts. The antivirus didn't stop it, because the converter isn't malware in the strict sense. The better question is why a standard user could run an unapproved program at all.
Application control answers that question by deciding which software may run, and sandboxing contains software you have to run but can't fully trust. On the CompTIA Security+ SY0-801 exam both sit under objective 4.1, which expects you to apply mitigating controls in a scenario; application control appears with its two approaches, allow lists and block lists, and sandboxing appears as a mitigation of its own. This lesson covers how the two list approaches differ, the rule types behind them and how each is bypassed, how Windows enforces them, and the main kinds of sandbox.
Application control decides what may run before it runs
Antivirus and EDR ask whether a program looks or behaves maliciously. Application control asks a simpler question: is this program approved on this system? The check happens before the code executes, when the operating system is asked to load an executable, script, installer or library.
That difference matters because a lot of unwanted software isn't malware. Unlicensed tools, remote access programs a scammer talked a user into installing, cryptocurrency miners and portable apps run from a USB stick may not trip a signature, but none of them belongs on a finance workstation. Application control can also stop brand-new malware, because it doesn't need to recognize the malware, only to see that it isn't approved.
Older material calls the two approaches whitelisting and blacklisting; CompTIA now uses allow list and block list, and so does this course.
Allow lists deny by default, and block lists allow by default
An allow list names the software that may run, and everything else is blocked. A block list names the software that may not run, and everything else is permitted.
| Allow list | Block list | |
|---|---|---|
| Default action | Deny | Allow |
| Stops unknown malware | Yes | No |
| Effort to maintain | High | Low |
| Risk of blocking real work | Higher | Lower |
| Best fit | Servers, kiosks, point of sale, OT, high-security desktops | Banning specific tools on general-purpose desktops |
An allow list is the stronger control, and the cost of running it is real. Every new application and every update has to be approved, a missed entry stops someone's work, and an emergency fix that ships a new executable can fail until the list is updated. That's why allow listing is one of the technical implications change management has to plan for. It fits best where the software set is small and stable: a point-of-sale terminal, a kiosk, a domain controller, an industrial control workstation. On general office desktops it's achievable but needs a mature process, usually built from an inventory of what people really run.
A block list is easy to deploy and rarely breaks anything, which is also why it's weak: it stops only what someone thought to list. It's the right tool for narrow jobs, such as banning a remote access tool attackers have been abusing, a torrent client, or a known-vulnerable version of an application.
On the exam, a scenario that says a system runs one dedicated application, must stop unknown or zero-day malware, or should run only approved software is pointing to an allow list. A scenario about banning one named program is pointing to a block list.