Baselining finance workstations is different. It's not about generic "user behavior." It's about locking down a predictable, high-risk function. If you're just looking for "suspicious process launches," you'll drown in noise. You need to baseline the *business process*.
Start with the data sources you already have. EDR telemetry is key, but don't ignore logs.
* **Process Execution:** Hash every approved binary. Finance should only run a tight list: Excel, your accounting software, a few browsers for specific SaaS portals. Everything else is a deviation.
* **Network Flows:** Map every expected destination. Your ERP system, bank portals, internal accounting APIs. Everything else is a deviation. This is where you'll catch C2 callbacks or data exfiltration to unknown IPs.
* **File Access:** What directories hold sensitive files? `\fin-serverpayroll`, `C:Financereports`. Monitor for unusual reads/writes, especially by non-finance apps.
Here's a basic Prometheus metric you could generate from parsed Windows Event Logs (using something like `windows_exporter` or a log scraper) to track anomalous process count. This assumes you have a known-good list.
```yaml
# Example alert rule for anomalous process
groups:
- name: finance_baseline
rules:
- alert: Finance_Workstation_Anomalous_Process
expr: sum by (host) (windows_processes{process_name!~"(excel.exe|acctpro.exe|chrome.exe|..."}) > 0
for: 2m
labels:
severity: high
annotations:
summary: "Non-baseline process on finance workstation {{ $labels.host }}"
```
The real work is in building that allowed list. It's iterative.
1. Collect 2 weeks of EDR process data during a quiet period (not month-end close).
2. Triage everything. Get finance leadership to sign off on the "allowed" list.
3. Implement detection on deviations in audit mode first. Tune out the false positives (the IT support tool used once).
4. Enforce.
Don't forget authentication. Baseline normal logon times and locations. A finance user logging in at 2 AM from a new country is a screaming alert, regardless of process activity.
Finally, baseline the *volume* of activity. A workstation suddenly generating 10x the network traffic or file writes is a signal, even if the destinations and processes look "normal."
— chrisw
Run it yourself.
You've nailed the core principle. The metric you've shown is a solid foundation for process execution anomalies. What often gets overlooked is that even within an approved binary like Excel, the command-line arguments and child processes can be highly revealing. Your baseline should include the typical invocation patterns.
For example, a finance user opening a locally saved forecast file is normal. Excel spawning `powershell.exe` as a child process to download a script from a remote URL is not, even if `excel.exe` itself is on the approved hash list. A more complete rule would also parse `CommandLine` logging.
Similarly, for your network flows point, the destination IP isn't enough. Baselining the specific URLs or API endpoints accessed through the approved browser is critical. A connection to the bank's domain is expected; a POST request to an obscure subdomain like `transfer.execute.bank.com` might be a huge deviation if your normal pattern is only GETs to `login.bank.com`. You need to integrate HTTP proxy or ZTNA logs into your flow analysis.
Great point about baselining the business process, not just generic behavior. The Prometheus rule is a good start for detection, but it can be noisy if an approved binary like `excel.exe` gets a patch and the hash changes.
For that process hashing, you might want to complement it with certificate validation or signer checks in your detection logic. That way, you can allow new versions from a trusted publisher without updating your hash list every month. Here's a quick example of what that filter could look like in your rule:
```yaml
# Add a condition for signed binaries from Microsoft
- source: '.*\excel.exe'
signer: 'Microsoft Corporation'
```
It catches tampered or unsigned versions while letting routine updates through.
Clean code is not an option, it's a sanity measure.
I completely agree with your focus on the business process. In marketing, we take a similar approach with high-value automations or analytics dashboards, locking down predictable workflows to detect compromise or misuse.
One nuance from the marketing automation side that might apply here: after you've defined the approved binaries and destinations, you need to *sequence* them. A normal workflow might be: start VPN client, launch ERP, download report to a specific share, open in Excel. If a user suddenly launches Excel first and it tries to connect to an external IP, that's a deviation even though both the app and the network flow might individually be approved. The order of operations can be a powerful signal.
—Anita
That business process focus makes sense. I've been trying to set up similar detection for our dev environment, and the noise is constant. How do you handle the initial data gathering without a full EDR? Are you just parsing local Windows event logs, or is there another source you'd start with?