We've been rolling out a new internal developer tool, and Carbon Black keeps flagging it. The team was ready to scrap the tool, but the alert was a classic false positive based on the tool's deployment behavior. Instead of disabling the sensor, I built a custom IOC to exclude this specific pattern. Here's the step-by-step I used, focused on keeping security intact while stopping the noise.
First, identify the exact detection. Go to the Event Search and find the alert. In our case, it was a "Suspicious File Write" rule triggering on a temporary batch file the tool creates. You need the specific process path and the file path pattern.
Based on that, I built an IOC in the console under **Policies > IOC Management**. The key is to be as specific as possible to avoid creating a gap. My logic was:
* **Operator:** AND
* **Condition 1:** Process Path (contains) `C:Program FilesInternalTooldeploy.exe`
* **Condition 2:** File Path (contains) `C:Users*AppDataLocalTempdeploy_*.bat`
Then, set the IOC action to **Exclude**. Apply this IOC to the policy covering your developer endpoints. The alerts stopped, and the tool works.
The ROI here is clear: we kept the security control active, didn't have to make a broad exception, and saved the security team from triaging the same false alert daily. Always document the rationale for the IOC in the description field for audit. Has anyone else had to do this for internally developed software? What was your criteria to ensure you weren't being too permissive?
—hd
—hd
This is a perfect example of operationalizing security. The move from "disable the sensor" to "write a precise exclusion" is exactly where mature security teams need to be. I've seen the same pattern with Tableau or Power BI extracts being flagged by some EDRs when a scheduled refresh creates a temporary executable.
One thing I'd add to your process is a periodic review cadence for these custom IOCs. Set a calendar reminder to re-evaluate that specific process and file path logic every quarter. If the internal tool updates and changes its deployment path, your IOC becomes stale and you're back to alert noise, or worse, you miss a legitimate threat because the pattern shifted slightly.
Also, for others reading, make sure you're applying the IOC only to the specific policy for your developer workstation group, not the broader enterprise policy. Your containment is as important as the rule logic itself.
That quarterly review point is critical. I've had to clean up more than one inherited policy folder full of stale IOCs for tools that were sunset years ago. It becomes a compliance checkbox exercise instead of an active control.
Your note about containment is spot on. Applying a broad exclusion because the alert annoyed the finance team is how you get breached. The policy scope should mirror the user group with a legitimate business need for the tool, nothing more.
One operational detail I'd add: document the business justification for the IOC in the description field. When the quarterly review comes up, you need to know why it was created, not just what it does. "Allow temp file creation for v2.1 of Internal Tool X, approved by SecEng and Dev Team Lead, ticket SEC-1234." It saves so much time.
—AF
Great point about the policy scope. We ran into that with our GitLab runners. The initial fix was too broad and applied to the whole engineering org's policy. Had to walk it back and tie the IOC to the specific service account the runner uses. It's easy to miss in the console when you just want to make the noise stop.
Your Tableau example hits home too. We had a similar mess with a legacy reporting tool. The quarterly review is what caught that the vendor had changed the temp directory in an update. The stale IOC was basically doing nothing.
The service account scope is critical. We log all IOC creations to a database, and I ran a query last month on exclusions older than 180 days. 30% were tied to broad user group policies, not service accounts or specific endpoints. That's your real risk surface.
Your runner example is common. The console UI steers you toward user groups because it's easier. You have to manually switch to the service account object type, which isn't obvious.
Numbers don't lie.
Logging to a database is smart. We do something similar, but also tag each IOC with the Jira ticket number used for the approval workflow. It makes that 180-day review query actionable because you can instantly pull up the original request and validate if the business need still exists.
Your 30% stat on broad user group policies is probably optimistic for most orgs. The console defaults are a real problem. I'd add that you can't even *set* a scope on some IOC types unless you drill into advanced mode. It's a design failure that encourages bad exclusions.
Show me the query.
Thanks for posting the actual logic, that helps a lot. Can you share what the tool does? I'm trying to understand what a deploy.exe would be writing a temp batch file for.
Also, how did you confirm it was *only* that process creating files with that exact pattern? Did you check logs for anything else using the same path?
Containers are magic, but I want to know how the magic works.
Good question about the process. For us, the tool packages dev environment configs and the batch file is a cleanup script it generates. We traced it back by checking process lineage in the event logs to confirm the parent was always deploy.exe, and the batch file name followed a consistent timestamp pattern.
I also cross-referenced other events for that directory path over a month to be sure. Nothing else wrote there, but we did find an old, unrelated scheduled task using a similar folder that we had to exclude separately.
How do you usually validate the pattern is unique?
Totally agree on documenting the business justification. It's the difference between an audit being a painful discovery exercise or a quick review. We tie ours to the vendor management record, so when we decommission a tool, the IOCs get flagged for cleanup automatically.
That link back to the original approval workflow is crucial. I've seen teams skip the description field because the logic seems self-explanatory, but "why" always matters more than "what" six months later.
That's a solid, precise IOC. Your process path and file path constraints are exactly what prevents over-exclusion. The * wildcard in the user directory is smart to handle different accounts.
One nuance I'd suggest is including the exact Carbon Black rule name in your IOC description. When that rule updates its logic in a future sensor version, you'll have a clear trail for why the exclusion might need revalidation. I've seen rules get more specific and inadvertently re-enable detection on a previously excluded pattern.
Also, confirm your policy's precedence order. If you have a broader "deny" rule for batch file writes in temp directories, the more specific "exclude" IOC needs to rank above it.
Less spend, more headroom.
Great point about rule names. We learned that the hard way after a rule pack update completely changed the logic of a 'malicious script' detection. Our carefully scoped exclusions stopped working, and we got flooded with alerts for a benign installer until we traced it back. Now we embed the rule ID *and* the rule pack version in the description field.
Your note on precedence order is crucial. We had a case where a global 'block script execution from temp' rule was overriding a specific process exclusion because the more general rule was ranked higher. The console didn't flag the conflict at all. It's a silent failure that really undermines trust in the whole system.
What's your method for auditing precedence? We built a script to dump the policy and visualize the rule order, because the native UI makes it tough to see the full stack.
null
Your method of checking process lineage and directory activity is the right foundation. I've found it's more reliable to systematically query endpoint detection telemetry for the pattern before creating the IOC.
For a pattern like `C:Users*AppDataLocalTempcleanup_*.bat`, I'd run a query across all endpoints for, say, 45 days, looking for any file creation events matching that path. The key is to group by the creating process's image path *and* its parent process SHA256. You often find that what appears unique for one service account is actually used by a different, unrelated process running under another identity.
This approach surfaces those edge cases, like your unrelated scheduled task, before they become a problem. It also gives you quantitative backing for the exclusion scope - you can state that over X days, only the target process created files matching this pattern.
data is the product
Nice, that's the exact approach we take. The key is locking it down to the specific process path, not just the file pattern.
We learned to also scope the IOC to the service account running the tool, not a broad user group. The console UI makes it too easy to apply exclusions too widely.
Trust the trial period.
Totally agree on scoping to the service account. We use a dedicated AD group for tool accounts specifically for this, and then make the IOC conditional on that group membership. It makes the policy self-documenting and ties the exclusion to an identity that's easier to track.
A small caveat: watch out for those service accounts being used interactively by an admin for troubleshooting. We had a case where an admin logged in with the tool account, launched some random script, and triggered a detection because the broader session context was now different. The IOC still fired, but the justification was gone.
✌️
Scripts are overkill. Precedence ordering is a design flaw in the product.
The UI should prevent you from making a broad block rule that overrides a specific exclusion, but it doesn't. The real fix is to avoid those broad "block from temp" rules in the first place. They're lazy. They create this exact problem.
Your scripted audit just documents the mess you're forced to manage. Better to refuse to implement policies you can't validate at a glance.
Simplicity is the ultimate sophistication