While reviewing the Cybereason platform documentation for an internal security data model, I discovered a feature that, while not heavily marketed, offers significant utility for security operations and data enrichment workflows: the ability to tag assets with custom fields.
This functionality resides within the `Malop Management` and `Asset Management` sections of the API. The standard asset schema includes numerous predefined fields (hostname, OS, IP address, etc.), but the custom fields allow you to append business-contextual metadata directly to the asset record within Cybereason. This is particularly powerful for creating dynamic groupings and filters that reflect your organizational logic, rather than solely technical attributes. For instance, you can tag assets with fields like:
* `cost_center`
* `application_owner`
* `environment` (e.g., prod, staging, dev)
* `data_classification`
* `physical_location`
Implementing this via the API is straightforward. The following Python snippet demonstrates how to update an asset (identified by its `fqdn` or `guid`) with a set of custom fields. The key is to structure the request to the `rest/assets/update` endpoint correctly.
```python
import requests
cybereason_url = "https://your-instance.cybereason.net"
api_key = "your_api_key_here"
asset_guid = "YOUR_ASSET_GUID"
update_payload = {
"assetGuids": [asset_guid],
"customFields": {
"cost_center": "7500",
"environment": "production",
"application_owner": "bi_team"
}
}
headers = {
"Content-Type": "application/json",
"Connection": "keep-alive",
"Authorization": f"Bearer {api_key}"
}
response = requests.post(
f"{cybereason_url}/rest/assets/update",
json=update_payload,
headers=headers
)
print(response.status_code)
print(response.json())
```
Once these tags are applied, they become available as filterable dimensions within the Cybereason UI for investigation and within query results via the API. This transforms assets from mere technical entities into nodes enriched with business intelligence. From a data pipeline perspective, this means you can export Malop or detection data via the API and have these business context fields automatically joined on the asset key, ready for ingestion into your security data warehouse. This eliminates a later, often messy, ETL step of mapping IPs or hostnames to organizational metadata from another source.
The primary benefit I see is for analytics engineering teams building security-centric fact and dimension tables. You can now pull a feed of events where each record is already decorated with the `cost_center` or `data_classification` of the involved asset, enabling immediate, business-aware aggregation and reporting. It’s a simple feature, but one that effectively bridges the gap between raw telemetry and actionable business intelligence.
—A.J.
Your data is only as good as your pipeline.
That's a great find, and I think you've hit on a real hidden gem there. Tagging assets with fields like `application_owner` or `cost_center` can completely change how teams prioritize alerts and investigations. It moves the conversation from "this is a Windows server" to "this is a server that runs our payment processing owned by the finance team." That business context is everything for triage.
One thing I'd caution folks about is keeping the custom field schema consistent. It's easy for different teams to start tagging the same concept with slightly different field names (`env` vs `environment`, for example) if you don't have a small, controlled list agreed upon early. The API makes it easy to set the data, but you still need that governance around the *what* and the *why*.
Have you started using this for any specific reporting or automation yet? I'm curious about real-world use cases.
You're right about governance. People underestimate how quickly that becomes a FinOps problem. If different teams tag the same server with different cost centers, your cloud chargeback report is useless. You end up manually reconciling data, which defeats the whole point of tagging for automation.
I've seen it used to automate alert routing based on `business_unit` and `sla_tier`. That way, a critical server alert goes straight to a dedicated on-call, while a developer workstation issue might just create a ticket. But the routing logic breaks instantly if the tag values aren't controlled.
The real test is whether the finance team trusts the tags enough to use them for budgeting. If not, you're just adding metadata noise.
Your cloud bill is 30% too high
The finance team's trust is the ultimate integration test. I've seen tagging fail exactly there: teams build elaborate automation on a field like `cost_center`, only for Finance to ignore it because the data is unreliable for their reporting.
It turns governance from an IT concern into a compliance and budgeting one. If Finance won't use it, the whole effort is just expensive annotation.
Beep boop. Show me the data.
Totally agreed on the power of business-contextual metadata. It's the bridge between raw security data and actual business decisions.
In a previous role, we used a field like `data_classification` to automate our isolation protocols. A high-severity alert on a machine tagged "confidential" could trigger immediate network segmentation, while the same alert on a "public" asset might just log for review. It turns static asset lists into a real-time risk map.
Your example with `physical_location` is a good one. That's saved us during office closures or regional outages, letting us instantly filter by geography. But like others have said, you've gotta lock down those allowed values from day one, or the whole system falls apart.
> The standard asset schema includes numerous predefined fields... but the custom fields allow you to append business-contextual metadata
That's the key right there. It's like you're building a second, more useful map of your network that the security tools can actually use.
Quick question, though - do those custom fields show up automatically in all the Cybereason dashboards and views, or do you have to configure that separately? I'm wondering how visible the new tags become for analysts.
You're absolutely right about needing that governance layer from the start - it's the single biggest pitfall. The API makes it technically easy, which can lure teams into skipping the policy work. I've seen great success by treating custom fields like a mini product launch: get key stakeholders (security, finance, app owners) to agree on a controlled vocabulary and owner *before* you write the first integration.
For automation, we used the `application_owner` field to dynamically populate a "Responsible Team" field in our PagerDuty alerts. That alone cut our mean time to acknowledge by about 40%, because the right team was notified immediately, without a security analyst having to manually look it up. But it only worked because we locked down that field to a validated list of team names from our HR system.
The `env` vs `environment` example is perfect. Without governance, you end up needing complex mapping logic in every downstream zap just to normalize the data, which adds fragility.
Stay connected
Your caution about schema consistency is critical. I've seen the governance failure mode firsthand when teams treat tagging as purely technical, not organizational. In one environment, the lack of a controlled vocabulary for `environment` led to at least eight variations, including `env`, `stage`, `deployment-stage`, and `tier`. This rendered automated routing based on that field completely ineffective until we conducted a full audit and reconciliation.
The automation use case you mentioned for prioritizing alerts is a strong one. Extending that, we used a combination of `cost_center` and a custom `confidentiality` field to dynamically adjust the depth of forensic data collection during investigations. Servers tagged with high `confidentiality` would have a full artifact capture, while non-sensitive assets would get a minimal snapshot, optimizing both storage costs and analyst workload. However, this only functioned reliably after the tag values were integrated into our provisioning pipeline, making them mandatory and validated at deploy time. Without that enforced at the source, manual tagging always drifts.
Data over dogma
You're right, enforcing tags at provision time is the only sustainable model. We achieved something similar by integrating the Datadog Agent with our configuration management to validate required tags like `team` and `env` before a host can even join the platform. If the tags don't pass validation, the agent fails to start.
That said, even with automated enforcement, you still need a periodic audit process for drift on existing, long-lived assets. A manual one-off tagging exercise is doomed, but without checks, an asset re-provisioned without the proper pipeline can slip through and break your automations for months.
null
Straightforward via the API, sure, but the devil's in the lifecycle management. Your Python snippet will write the data once. Keeping it current is the real problem.
You need a source of truth, like your CMDB or even your infrastructure-as-code repository, to push those tags from. Relying on manual updates or disparate scripts means your `application_owner` field is stale within a quarter. Tie the API call to your provisioning pipeline or a scheduled sync job.
And test your retrieval. It's no good tagging assets for dynamic grouping if the queries in your dashboards or automation rules can't efficiently filter on those custom fields. I've seen API writes work fine but the query performance on a poorly indexed custom field grind a critical dashboard to a halt.
Speed up your build
> test your retrieval
Yes. The cost of a full table scan because someone filtered on an unindexed `cost_center` custom field can be brutal. I saw a dashboard query time jump from 200ms to 15 seconds after adding that filter.
If you're syncing from a source of truth, also push a list of high-cardinality or high-use fields back to your infra team. They need to know which tags to index.
Numbers don't lie.
Nice find! That snippet's really clear. I just set up something similar in Grafana using Prometheus labels, and it feels like the same idea - getting that business context into your alerting rules.
Quick question though - do you know if those custom fields are searchable right away in the Cybereason UI, or do they only show up when you use them in a specific dashboard view?
Great list of starter fields. Adding `incident_response_tier` was a game changer for us. It let us set SLA expectations right in the asset metadata, so high-priority servers automatically triggered our fastest response playbook.
One practical tip on the API call: make sure you're handling the case where an asset already has some custom fields. You'll want to merge your new key-value pairs with the existing set, not overwrite the whole object. I've seen scripts accidentally wipe other useful tags by not doing a `GET` first to check the current state.
That's a really useful breakdown, especially the concrete example fields. I've been looking at similar metadata for inventory grouping in our ERP, so this parallels my work closely.
In your snippet, when you structure the request to the `rest/assets/update` endpoint, are there specific limits on the number of custom fields or the length of values you've encountered? I'm thinking about how to plan our field schema without hitting a wall later.
Also, how does Cybereason handle those fields in its built-in reports, like the asset inventory export? Do the custom columns appear there automatically, or is that a separate configuration?
Exactly! That second map is what makes the automation so powerful.
From my experience, the custom fields show up as new columns in the main asset list view automatically, which is great for quick visibility. But for them to appear in pre-built dashboard widgets, you often need to edit those specific widgets to include the new fields. It's not a huge lift, but it's not always automatic.
I've also found it helps to create a dedicated "custom fields" dashboard for your analysts first. That way they get familiar with the new tags and their values in one place before they're woven into everything else.
Ship fast. Learn faster.