Alright, I've been putting CrowdStrike Intel through its paces for a few weeks now, specifically trying to figure out if the 'priority' scoring is a game-changer or just another number to ignore.
On paper, it sounds great—automatically scoring threats based on adversary sophistication, victimology, and malware confidence. But in the daily triage flow, does it actually change what you look at first? I've had some IOCs with a high 'priority' score that, when I dug in, were linked to older campaigns we'd already mitigated. Meanwhile, a medium-priority alert yesterday turned out to be a fresh TTP we hadn't seen before.
My current take:
* The score is useful **as a starting filter**, but you can't rely on it blindly. It gets you in the ballpark.
* It seems most effective when you combine it with your own internal tags (like "critical assets").
* I wish there was more transparency on how the score is weighted. A breakdown would be huge.
Has anyone else compared their manual assessment against the priority score? Are you actually letting it dictate your queue, or is it just another column in the spreadsheet? Would love to see how others are fitting this into their workflow.
> It seems most effective when you combine it with your own internal tags
That's the only way it works. Any generic priority score from a vendor is, by definition, blind to your actual environment. Their "victimology" is a broad category, not your specific crown jewels.
We tried letting it dictate the queue early on. It pushed a high-priority alert for a banking trojan to the top. We're a SaaS platform with no financial data processing. Total waste of cycles. The medium-score alert on a weird container escape attempt? That was the real fire.
The scoring is a decent input, but if you're not feeding it your own asset criticality and vulnerability data, it's just noise. Treat it like a single sensor, not the SIEM.
trust but verify
Exactly right about the older campaigns. That's the vendor's generic context colliding with your own history. The score can't know you've already burned the playbook for that specific adversary group.
Where it becomes actively dangerous is when you let it dictate order in a queue without a heavy decay factor for time. I've seen teams miss novel, low-precision attacks because a high-scoring re-run of last year's script was sitting at the top of the list for two days. It creates a weird form of alert debt.
Your point on weighting transparency is the core issue. Without it, you can't tune the signal. It's like getting a risk score from a black-box ETL job with no data lineage - you have to trust it completely or ignore it, with no sane middle ground.
Expect the unexpected
"Alert debt" is a perfect term for it. That's the real cost they never put in the sales brochure. You pay for the platform, then you pay again in analyst time sifting through its own stale, high-confidence ghosts.
The weighting transparency is the real joke. You're asking a vendor whose entire business model is based on proprietary 'secret sauce' to suddenly give you the recipe. They'll talk about factors and inputs all day, but the moment you ask for the actual coefficients so you can adjust for your environment, you hit a wall of "that's part of our core algorithm."
So you're left with exactly the two useless options you mentioned: blind faith or total dismissal.
Buyer beware.
Totally feel your pain with the older campaign IOCs getting high scores. We ran into the same thing, but from a different angle: our own automation.
We treat the priority score as just another input to a Terraform module we built for alert routing. It gets combined with our internal asset tags (like you mentioned) and a time decay factor someone else pointed out. The key was adding a feedback loop - if we manually override the queue position, that gets logged back as data to adjust the weights in our own scoring formula.
So the vendor's "black box" score becomes a single variable in our transparent, version-controlled equation. It's not perfect, but it keeps us from blindly trusting a single number.
Are you feeding these scores into any automated routing, or is it all manual triage at your end?
State file don't lie.
> feeding these scores into any automated routing
That's the trap. Now you've baked their opaque scoring into your own "transparent, version-controlled" logic. You're just adding a layer of complexity on top of the black box.
I've seen this blow up. Your Terraform module inherits all the vendor's stale signals and suddenly you're automating bad decisions. The feedback loop helps, but you're still starting from garbage data. You're just polishing a turd.
If you must use it, keep the automation dumb. Route based on your own tags and decay. Let their score be a display field for an analyst to glance at, nothing more.
-- old school
I strongly disagree with the "garbage in, garbage out" premise here. It misrepresents how integration works. Treating a vendor score as an atomic, untunable input is the actual trap.
You're not just "polishing a turd" by using it in automation, you're *contextualizing* it. The whole point of a feedback loop is to measure the delta between the vendor's prediction and your actual disposition, then use that to apply a corrective factor. Over time, your system learns to discount their score for, say, banking trojans against your SaaS assets. The black box becomes a weighted feature, not the decision.
The real risk isn't inheriting stale signals, it's building a static pipeline with no feedback. Your example of it blowing up sounds like a one-way integration. The solution is to make it two-way, not to dumb down the automation. A display field adds manual toil and guarantees the score is never challenged or improved upon systematically.
IntegrationWizard