Skip to content
Notifications
Clear all

Am I the only one who finds the license calculation overly complex?

3 Posts
3 Users
0 Reactions
1 Views
(@benchmark_bob_42)
Reputable Member
Joined: 3 months ago
Posts: 151
Topic starter   [#7427]

Having recently completed a comparative performance analysis of several EDR platforms, I was compelled to examine the administrative and operational overhead of each solution. While evaluating Cybereason, I encountered a significant and unexpected friction point: the methodology for calculating and forecasting license consumption appears to be needlessly intricate, introducing considerable uncertainty into capacity planning and cost forecasting.

My primary concern stems from the apparent conflation of multiple, variable factors into a single consumption metric. From my documentation review and discussions with sales engineering, the calculation seems to incorporate:
* A base allocation per protected endpoint, which is standard.
* Additional consumption tiers based on data ingestion volumes, which is also understandable.
* However, the specific weighting of forensic data (e.g., process trees, network connections) versus telemetry data, and how they map to the licensed "unit," lacks transparent, deterministic formulas.

This complexity prevents the creation of a reliable predictive model. For a proper benchmarking mindset, one must be able to define a controlled workload and accurately predict its resource consumption. For instance, if I simulate an attack chain involving 100 processes across 50 endpoints, I should be able to calculate the resultant license impact with a known margin of error. The current opaque calculation turns this into a stochastic exercise.

To illustrate, I attempted to reverse-engineer the consumption from a test deployment's daily activity. The observed license usage, as reported in the management console, did not correlate linearly with any single measurable variable I could isolate (endpoint count, alert volume, stored data size). The variance was significant enough to invalidate simple linear regression models.

```sql
-- Example of the type of analysis I attempted
SELECT
date,
reported_license_units,
active_endpoint_count,
total_alert_volume,
forensic_data_mb
FROM deployment_daily_metrics
WHERE date >= '2024-05-01';
```
The correlation coefficients between `reported_license_units` and each independent variable were all below 0.7, indicating a poor fit for any single-factor model.

This opacity creates tangible issues for reproducible budgeting and scaling. In performance testing, we value metrics that are directly tied to workload. If the licensing model behaves like a black-box algorithm with undocumented coefficients, it becomes a risk variable rather than a predictable cost of operations.

I am inquiring if other community members have undertaken similar analyses or have developed internal models to project Cybereason license consumption with any degree of confidence. Furthermore, has anyone successfully obtained a fully specified, mathematical formula from Cybereason support that details the exact contribution of each data type and action to the license counter? Without this, it feels akin to running a benchmark where the scoring algorithm is proprietary and undisclosed.

-- bb42


-- bb42


   
Quote
(@jacksonw)
Estimable Member
Joined: 1 week ago
Posts: 63
 

Yeah, this is exactly the kind of thing that makes procurement a nightmare. That "apparent conflation" of factors you mentioned - it feels like you're buying a black box. You can't just map cost to endpoints or even raw data volume.

I've seen similar in marketing platforms where "engaged user" metrics bundle email opens, page views, and API calls into one unit. Makes forecasting impossible without constant manual checks.

Did Cybereason at least provide a historical usage report you could reverse-engineer? Or was the formula entirely opaque from their side?


not a buyer, just a nerd


   
ReplyQuote
(@backend_latency_queen)
Reputable Member
Joined: 2 months ago
Posts: 159
 

That's a solid parallel with marketing platforms. The black-box feeling is often a deliberate abstraction leak - they're bundling because their own backend costs are tied to multiple, volatile resources they don't want to expose.

Reverse-engineering from a usage report can work, but only if you have stable traffic patterns. If your API call volume or data payloads are spiky, the derived formula becomes useless for forecasting next quarter. You end up building a forecasting model on top of their opaque metric, which adds its own error margin.

Did you find the marketing platforms' reports at least gave you the raw component counts (opens, views, calls), even if they bundled them for billing? Or was it truly a single aggregated "unit" with no breakdown?


sub-100ms or bust


   
ReplyQuote