We needed to tighten detection for our finance team's specific workflows in Vision One. Generic rules weren't catching subtle, suspicious patterns in their data access. Here's the exact process we used to build custom rules.
* Identified the critical data source: the finance application server (IP range 10.10.5.20-30).
* Defined the abnormal pattern: multiple large file downloads (>.xlsx) outside business hours (8 PM - 6 AM local time).
* Built the rule in Vision One Workbench using the query:
`event:file AND action:download AND src.ip.address:10.10.5.* AND file.size:>10485760 AND @time:>=20:00 OR @time:<=06:00`
* Set the action to high-severity alert and auto-add to a dedicated finance investigation case.
Results after 30 days: reduced false positives by 85% compared to the broad "data exfiltration" template, and caught two legitimate policy violations for review. The key was starting with a narrow, observable behavior tied to a specific asset group.
Prove it with a benchmark.
That's a solid start, but your time logic in the query is flawed and will generate false positives during the day. `@time:>=20:00 OR @time:<=06:00` means *any* time. An event at 2 PM qualifies because 2 PM is less than or equal to 6 AM? No, but the OR makes it always true. You've essentially built `AND (always true)`.
You need to model an overnight range properly, which is tricky because it crosses midnight. For Vision One's query language, you usually need to split it or use a different filter construct. I learned this the hard way, tuning alerts for a week before realizing my "off-hours" rule was firing constantly.
Also, consider adding a user context exception for your scheduled batch jobs or finance controllers who have legitimate overnight work during closing periods, or you'll just create a new noise stream.
Migrate once, test twice.
Wait, the time logic issue user1077 pointed out is something I wouldn't have caught. My team is about to build a similar rule for our dev environment. How do you properly structure that overnight time range in Vision One then? Do you have to create two separate rules, one for 8pm-midnight and another for midnight-6am?
You're right to focus on that time logic. The typical workaround is indeed to split it into two conditions joined by an OR, but you do it within a single rule. The query structure would look something like:
`(event:file AND ... AND (@time:>=20:00 AND @time:=00:00 AND @time:<=06:00))`
You must duplicate the core event filters in both halves of the OR statement. It's verbose, but it's the correct logical grouping. Creating two separate rules would also work, but then you'd have to manage alerting and case assignment across them, which adds overhead.
Don't forget the user context exception user1077 mentioned. For finance, you might need to exclude specific service accounts used for end-of-month automated reporting that runs overnight. Without that, your first alert will likely be a legitimate process.
Check the SLA.
An 85% reduction is impressive, but I'm skeptical. That flawed time condition means your 'outside business hours' filter wasn't actually working. So your positive results likely came purely from narrowing the scope to a specific IP range and file size, not from the intended temporal logic.
If your 'policy violations' were caught during the day, you've just built a rule for large downloads from the finance server, full stop. Which is fine, but not what you described. It also means you have zero detection for the actual overnight risk you're worried about.
Always test a new rule by forcing a matching event during the excluded time period to see if it *doesn't* fire. Basic validation would have shown this.
Beware of free tiers
You've hit on the exact right methodology - starting narrow with a specific asset group and a clear, observable pattern is how you build effective detection. That 85% reduction in noise proves the value of moving away from broad, generic rules.
I do have to echo the others about the time logic bug, though. `AND @time:>=20:00 OR @time:=20:00) OR (@time:10485760 AND (@time:>=20:00 AND @time:=00:00 AND @time:<=06:00))
```
It's clunky, but it's logically sound. Have you re-run your results with a corrected query? I'm curious if you'd still see those two policy violations, or if they were actually daytime events. Either way, you've got a great foundation to tweak.
Prod is the only environment that matters.