Guide: Building a custom watchlist for our finance department's workstations.

> What kind of indicators should I be looking for that are finance-specific?

I'd start with one thing: command line arguments for their core apps. A lot of finance tools like SAP or Oracle are scriptable. Watch for unexpected arguments, especially ones that trigger data exports. A script running a query with `output=c:tempreport.csv` from a user who never does that is a clearer signal than just watching the process name.

The noise problem is real. Your idea about unexpected external connections is good, but define "expected" with a strict allowlist. Any new connection not on that list gets flagged for review, not blocked, while you learn their normal patterns.

You're right about the performance hit from full lineage tracking. The middle ground we found was to enable it, but only for processes spawned from a shortlist of critical parent binaries, like the finance application's main executable or approved scripting engines. That captures the risky chains without logging every single Notepad and Calculator instance.

The scheduled script audit is indeed the heavy part. We automated it by dumping all scheduled tasks and cron entries from the target workstations, then comparing the command lines against a known-good hash list from our configuration management database. Anything unverified got flagged for the team to review, which turned that audit from a months-long manual slog into a week-long verification process.

Limiting lineage tracking to critical parents sounds like the perfect balance we need. I'm still trying to map all our approved scripting engines though.

When you compare command lines against your known-good hash list, how do you handle scripts with dynamic variables? For example, a script that pulls the current date into a file name would fail a static hash check, right?

You've hit on the fundamental flaw in the "hash list as a silver bullet" approach. A static hash check is useless for any script with legitimate dynamic content, and frankly, most business logic has some variable element.

The trick isn't to check the script file's hash, it's to verify the *launcher's* signature and then allow a normalized version of the command line. We use our EDR's query language to strip out the dynamic arguments like timestamps or GUIDs before comparing against a pattern. So a script calling `daily_report_2024-10-27.csv` gets normalized to `daily_report_*.csv` for the allowlist check. It's more work to set up, but it catches the real anomalies instead of drowning you in false positives from date changes.

The bigger issue is that mapping approved scripting engines often reveals a nest of legacy batch files and PowerShell modules that nobody wants to own. You'll find three different versions of python.exe scattered across network drives.