Hi everyone, I’m relatively new to Cybereason and have been tasked with helping our team configure exception management. We operate a multi-tenant environment where we manage security for several distinct internal business units, each with their own set of approved exceptions.
I understand the basic process for creating an exception, but I’m looking for guidance on structuring this at scale. Specifically, how do you effectively organize and track exceptions across multiple tenants to ensure each unit only sees and manages their own, while still allowing central oversight?
Could someone compare the approach using Malops vs. the Exceptions view in the Management console for this purpose? I’m particularly interested in:
- How tagging or categorization is best applied per tenant
- The workflow for reviewing and approving exceptions in bulk across different units
- Any limitations in reporting that might make one method preferable over the other for audit purposes
Our main goal is to maintain clear separation without creating administrative overhead. Any insights from your own setups would be very helpful.
Thanks!
I'm George, and I've been running a self-hosted security monitoring stack for a managed services provider handling about 30 distinct client environments, using a mix of open-source tools and Cybereason for endpoint, all orchestrated through Docker Swarm.
The Malops view and the Exceptions Management console serve fundamentally different purposes, and the "best" method depends on whether your primary need is investigative workflow or administrative control. Here are the concrete criteria for your multi-tenant scenario:
1. **Tenant Separation Clarity**:
* **Exceptions Management Console**: Clearly wins for structured administration. You can enforce separation using the `scope` field in the exception rule itself, tying it to a specific sensor group tied to a business unit. I've seen this hold up cleanly across 30+ tenant groups.
* **Malops View**: Separation is investigative and relies on manual tagging after the fact. It's possible to filter by machine or tag, but there's no native enforcement to prevent an analyst in Tenant A from viewing or acting on a Malop from Tenant B without disciplined process.
2. **Bulk Workflow & Approval**:
* **Exceptions Console**: Built for this. You can export pending exceptions to CSV (about 5000 rows at a time in my experience), have unit managers review their subset, then use the API to batch-approve or reject. We scripted this using `curl` and a simple Python wrapper.
* **Malops**: No native bulk approval for exceptions. Creating an exception from a Malop is a one-off, per-alert action. For scale, this became a 2-3 minute manual task per item for our team.
3. **Reporting & Audit Trail**:
* **Exceptions Console**: Provides a dedicated audit log for the exception lifecycle (created, approved, expired, modified). We pull these logs nightly via API for our compliance checks. The data model is consistent.
* **Malops**: An exception created from here will still appear in the main exceptions log, but the linkage to the original investigative context can get fuzzy in reports. For our quarterly audits, pulling a clean report of "exceptions approved by Business Unit X" was only reliable using the Exceptions console data.
4. **Initial Configuration Overhead**:
* **Exceptions Console**: Requires upfront design. You must map your business units to sensor groups and potentially configure custom roles for unit managers. This took us roughly 40-50 hours to design, implement, and document.
* **Malops**: Lower initial overhead, as it uses your existing detection environment. However, the long-term administrative overhead for maintaining separation is higher, requiring strict procedural controls to avoid cross-tenant visibility issues.
My pick is the **Exceptions Management console** for your stated goal. It's the correct tool for centrally governed, policy-driven exception handling across distinct units. If your primary constraint is having zero time for upfront sensor group redesign, or if your tenants are not cleanly mappable to discrete sensor groups, tell us that. If your need is actually for letting each unit investigate *first* and create exceptions ad-hoc from their investigations, then a governed Malops workflow with strict tagging could be forced to work, but it's the harder path.
George has outlined the core architectural distinction well. Expanding on the tenant separation point, the critical factor for your goal of central oversight without administrative overhead is the underlying data model. The Exceptions console is built on a rule-based system where the scope is an inherent property; this creates an enforceable boundary. The Malops view is an investigative lens over event data, where separation is achieved through filtering - a functional but not administrative boundary.
For your specific questions, tagging in the Exceptions console should be redundant if you've correctly scoped rules to sensor groups representing each business unit. Categorization is best applied at the exception rule level (e.g., "BU-A: Approved Tooling") rather than via post-hoc tags. Bulk review is only pragmatically possible in the Exceptions console, as you can filter by scope and approve/deny in batches. The Malops view requires individual Malop resolution.
The major reporting limitation for audits is provenance. An exception rule has a clear creator, scope, and modification history. An exception applied via a Malop decision is tied to that investigation's context, which can become fragmented across multiple tenants unless your filtering is meticulously documented. For audit trails, the console's structured data is superior.