Totally agree on the user context check for 7-Zip and Python, that's a lifesaver. It reminds me of a similar tweak we had to make for our own rule set.
We found that even within a user session, you can get tripped up by browser downloads. A finance analyst might download a ZIP file from a vendor portal through Chrome, which triggers a 7-Zip process to unpack it. That's still legitimate user activity, but it looks the same as someone manually running it to package internal data. The key was adding a parent process filter to exclude instances launched by `chrome.exe` or `msedge.exe`.
The scheduled task distinction is crucial, but sometimes the line blurs when a user kicks off a long-running script manually and walks away. Your window of risk after a job closes is spot on.
Happy testing!
Great point about browser downloads being a legitimate trigger. That parent process filter is a smart workaround. It makes me wonder about other trusted "launcher" processes we might need to consider, like email clients or the Windows shell when a user double-clicks an attachment from a trusted source.
The manual script execution you mentioned is a tricky gray area. How do you folks handle differentiating between a user launching a script they need and a suspicious interactive session? I've seen teams try to whitelist specific script paths, but that gets messy fast.
Keep it civil, keep it real.
Yeah, that parent process whitelist approach is how we handled it. We built a list of trusted launchers beyond the browser: `outlook.exe`, `explorer.exe` for double-clicks, and even our approved remote access client.
For the manual script gray area, whitelisting paths *did* get messy for us too. We shifted to a context rule instead: we allow it if the script process is spawned by one of those trusted parents **and** the logged-on user matches the finance security group. It's not perfect, but it cuts down on the noise from legitimate, interactive power-user work. The real alerts are for scripts run by a system account or a service.
That context rule for manual scripts is clever, but you're building a licensing liability. If you're tying a permissive rule to a security group, you better have absolute control over who's in that group. Finance teams are notorious for adding contractors, interns, or third-party auditors to those groups for access reasons, completely bypassing your control intent.
Also, watch your EDR licensing costs if you're letting that rule run 24/7. You're paying per-endpoint to monitor a process that you've essentially decided to ignore for a specific group. It's more cost-effective to create a separate, strict policy for the finance workstations and just accept the occasional false positive for a manual script, then tune it quarterly.
Your cloud bill is 30% too high
You're on the right track wanting to make it workflow-specific, but you're risking an unmanageable rule set if you start with indicators like external services and file patterns. Those are outputs, not root causes.
The most effective starting point is to invert your thinking. Instead of hunting for "finance-specific" threats, you need to first exhaustively define "finance-specific normal." That means capturing every single process and network connection from those workstations over a full business cycle, ideally a month. The goal is to build a sanctioned application and process tree map, not just a list of bad things. Your primary watchlist condition should be a deviation from that established process tree, particularly any new outbound connection spawned by an unsanctioned parent process.
A common and costly pitfall is building permissive rules tied to security group membership, as hinted later in the thread. You create a licensing and control problem, paying for monitoring on processes you've decided to ignore for a dynamic group you likely don't own. It's more operationally sound to build a strict baseline policy for those workstations and handle the few legitimate quarterly script exceptions via a separate, time-bound approval process.
Great question! The key is to avoid getting lost in the "finance-specific" trap of chasing external services right away. That's where the noise comes from.
Start by focusing on what's normal for *their* machines. Build a baseline of every single process and connection over a full month to see their actual workflow. The most useful rules we set up were deviations from that sanctioned process tree - like a new, unknown process spawning an outbound connection.
A big pitfall is making rules too permissive for convenience, like whitelisting by security group. It can create blind spots when temporary users are added. Sometimes it's better to have a stricter policy and handle a few false positives manually, then tune it down the road.
Automate all the things
That point about focusing on the workflow and building a baseline from a month of data is really helpful. I'm also new to this and was wondering the same thing about what "finance-specific" really means.
But I'm stuck on the first practical step, like user333 mentioned. How do you actually build that baseline without drowning in data? If I query for every process start, won't I just get a huge CSV file that's impossible to sort through manually? Is there a typical method to filter that initial data dump into something you can actually analyze to find those normal process trees?