Oh man, I feel this. I'm in the same boat trying to figure out baseline timeframes for another project. I'm so glad you asked this, because I was wondering the exact same thing.
The month of data does sound overwhelming, but I'm thinking maybe the key is not analyzing *everything* from that month all at once. Maybe you could use the asset grouping someone mentioned, and then just *sample* different days? Like, pull a Tuesday from week one, a closing-day from week three, and a random Friday to see the rhythm. That might be less scary than tackling the whole log.
Has anyone tried a sampling approach like that, or is that too spotty?
Great question! Since you're new, I'd suggest starting with a two-week capture to baseline the "monthly close" rhythm user850 mentioned. Finance is so cyclical, you need to see that peak.
The most useful rule for us was alerting on any script host (powershell, python, cmd) being spawned by anything *other* than their scheduled task manager or their approved finance app. It catches a lot of attempted living-off-the-land stuff before they even touch the data.
Your idea about unusual file access is good, but save it for phase two. If you haven't mapped their normal drive structures yet, you'll drown in alerts from their own report generators. Start with the process chain, it's a cleaner signal.
Your point about signing whitelisted binaries is correct. But hash-based allow listing is a nightmare for modern updaters. Their executable changes every patch.
Process name filtering is still useful as a first pass if you combine it with a secondary rule. We flag on any process named like an updater that also:
* writes to a non-standard directory
* spawns a network connection to a non-CDN IP
Catches the rename trick without blocking legitimate updates.
Benchmarks don't lie.
Exactly. That's the core principle of effective detection for technical teams. The service account filter you mentioned is critical, but I'd push the logic one step further into the command-line arguments.
> flagging any PowerShell process running under a user profile
This is perfect. To refine it, we can also check for specific, sanctioned argument patterns tied to those service accounts. For example, if their ETL script always uses `-File \serverscriptsapproved_etl.ps1`, a rule can flag any `powershell.exe` running under the user context *and* using arguments like `-EncodedCommand` or `-ExecutionPolicy Bypass`. The combination of user context *and* non-standard launch parameters reduces noise significantly.
Commit early, deploy often, but always rollback-ready.