[EN] Application Control Deep Dive: Appscan, the Reputation Service & Developer Protection

[jorgeluiznim]

Article 15 of the Harmony Endpoint Deep Dives series · A note on management: Harmony Endpoint is managed in the cloud through the Infinity Portal (Web Management). Application Control lives under Policy > Access & Compliance > Application Control, apps under Manage > Manage Applications.

Most allow-listing projects die the same way. Someone blocks applications by name, an attacker renames malware.exe to notepad.exe, and the whole control turns into theater. Application Control does not play that game: it identifies every program by an unforgeable checksum, not by its name. A renamed binary fools nobody. That single design choice is what makes the rest of the blade worth trusting, so everything below builds on it.

TL;DR
Identity is by checksum, not name. You build the inventory by scanning a clean reference machine with Appscan. Five permission states decide allow, block or terminate. The Reputation Service tightens your "unidentified" defaults but never overrides an explicit rule. Terminate kills the process, not just the port. And Developer Protection stops secrets from reaching Git.

What you need before starting: a malware-free reference computer per standard image (for Appscan), and the basics of the Access & Compliance policy (Article 1). That is it.

---

Two things make it trustworthy

Application Control restricts network access for the applications you choose, and it can allow, block or terminate a process, including killing one the moment it tries to reach the network. Two mechanisms carry the weight:

• Checksum identity, each application and version has a unique, unforgeable checksum, so a malicious program cannot pretend to be an innocent one.
• Reputation Service (the old Program Advisor), an online service that classifies apps as approved or not approved, based on Check Point research and the app's signed-certificate hash.

---

Building the inventory with Appscan

You do not type application names. You scan a reference computer, a tightly controlled, malware-free image with the typical apps your org uses, one per standard build. The flow looks like this:

diag1-appscan-workflow

Appscan is a CLI tool. In the cloud console you get it from Policy > Access & Compliance > Manage > Manage Applications > Download Appscan (also in sk108536), then run it on the reference device. Basic syntax:

Appscan [/o<filename> /s<targetdirectory> /x<extensionstring> /e /a /p /verbose /warnings /?]

/o sets the output file (default scanfile.xml); each application and version gets its checksum. One thing to do before importing the XML: strip special characters (trademark and copyright symbols), or the import can fail.

---

The five permission states

Every app in the inventory sits in one of five states:

Permission	Meaning
Unidentified (Allow)	Imported, not classified, allowed because the default is "Allow unidentified applications"
Unidentified (Block)	Imported, not classified, blocked because the default is "Block unidentified applications"
Allow	Explicitly allowed by the admin, overrides the Reputation Service
Block	Explicitly blocked by the admin, overrides the Reputation Service
Terminate	The app is terminated when it tries to reach the network, or immediately on run

• The Allowed Applications List is Unidentified (Allow) plus Allow, and users can only use those.
• The Blocked Applications List is Unidentified (Block) plus Block plus Terminated.
• The Versions section shows each version's number, Hash (signer) and Created On date, so you can allow one version of a program and block another.

---

How the Reputation Service tilts the defaults

This is the part worth getting right. When the Reputation Service is on, the client combines its recommendation with your policy permission:

Reputation	Policy setting	Client decision
Approved	Unidentified (Allow/Block) or Allow	Allow
Approved	Block	Block
Not Approved	Unidentified (Allow/Block) or Block	Block
Not Approved	Allow	Allow

Read the table twice and two rules fall out:

• An app set to Unidentified (Allow) that reputation marks Not Approved ends up blocked. Reputation quietly tightens your loose default, which is exactly what you want.
• An explicit Allow or Block always wins. Reputation never overrules a decision you made on purpose.

My take: turn it on. You get "block the bad unknowns" for free, without hand-classifying every tool in the building, and your deliberate rules still rule. One cloud-era note: reputation is reached through Check Point's cloud, so the old on-premises local.properties proxy tweak is gone. Just make sure clients can egress to the Reputation and ThreatCloud endpoints.

---

Terminate: killing the process, not just the port

Configured under Access & Compliance > Application Control, in two flavors:

1. Terminate on connection, the app is killed when it tries to reach the network. Things that never touch the network (Notepad, Calculator) are left alone.
2. Terminate on execution, selected by default, the app is killed the moment it runs.

Note: termination needs the clients and the Compliance policy configured to allow it (see sk141692). This is where Article 14 and this one meet.

---

WSL control

Windows Subsystem for Linux runs Linux binaries under Windows, which is a real and often ignored surface. Application Control can Disable WSL Traffic or Enable WSL Traffic straight from the rule. If you have not thought about WSL in your allow-listing, now is a good moment.

---

Developer Protection: stopping secrets at git commit

This is the modern standout, and the feature people do not expect to find in an endpoint product. Developer Protection stops developers from leaking sensitive data (RSA keys, passwords, access tokens) through Git, and flags vulnerable external dependencies (for example in AWS Lambda). It sits right at the commit:

diag2-developer-protection

Mode	Behavior
Disabled	Default
Detect	Leak detected, logged, developer notified, but the commit proceeds
Prevent	Leak detected, logged, and the commit is blocked. The developer can override (with or without justification), and the notice even suggests the fix: add to .gitignore, bump the version in package.json

On a developer fleet I would run Detect first to see the noise, then switch to Prevent. Stopping a credential at commit is a lot cheaper than rotating it after it hits a public repo.

---

How I would roll it out

• Build the Appscan inventory from a clean reference image per standard build. A compromised reference poisons the whole whitelist, so this is not the step to rush.
• Enable the Reputation Service so unidentified "Not Approved" apps are blocked for you, while your explicit Allow/Block rules stay authoritative.
• For true allow-listing, set the default to Block Unidentified Applications, but pilot it first. Flip that switch org-wide on day one and you will block legitimate tools and spend the afternoon on the phone.
• Turn Developer Protection to Prevent on developer machines, after a short Detect period to gauge impact.

---

Mistakes to avoid

Mistake	Impact	Fix
Scanning a reference computer that is not clean	Malware gets whitelisted	Use a controlled, malware-free image
Importing an XML with trademark/copyright chars	Import fails	Strip special characters first
Expecting Reputation to override an explicit rule	It does not, admin Allow/Block wins	Use explicit rules deliberately
Setting Block Unidentified without a pilot	Legit tools blocked, helpdesk storm	Pilot, classify common apps first
Assuming Terminate stops Notepad	Non-networking apps are not terminated	Terminate targets network-touching apps, or use Terminate on execution

---

One troubleshooting case

Symptom: an app marked "Unidentified (Allow)" is being blocked.
Why: the Reputation Service classified it Not Approved, which tightens the "Unidentified (Allow)" default to Block.
Fix: if you trust the app, set it to an explicit Allow (that overrides reputation), and check the version Hash matches the one you mean to allow, since permissions are per version.

---

Quick answers

What wins, my rule or reputation? Your explicit Allow/Block, always. Reputation only decides for unidentified apps.
Block vs Terminate? Block denies network access; Terminate ends the process (on network access, or immediately on execution).
Can I allow one version and block another? Yes, permissions are per version (each has its own number and Hash).

---

That is Application Control end to end: checksum identity, a clean inventory, reputation tightening your defaults, and Developer Protection catching secrets before they leave the laptop. How are you handling allow-listing today, strict Block Unidentified or Reputation-assisted? Curious how others pitch the pilot internally.

---

Related & sources

• Compliance Deep Dive, Article 14 (Terminate needs Compliance configured)
• Check Point Harmony Endpoint Administration Guide (cloud / Infinity Portal), Access and Compliance Policy > Application Control (Manage Applications, Appscan, checksum identity, permission states, Reputation Service, Terminate, WSL Traffic, Developer Protection)
• sk108536 (Appscan) and sk141692 (Terminate configuration)

Harmony Endpoint cloud management (Infinity Portal / Web Management), Windows clients.