Using VRM for MSSPs
Overview of MSSP Mode
Swimlane's Vulnerability Response Management (VRM) solution supports Managed Security Service Provider (MSSP) scenarios, enabling a central tenant to aggregate, monitor, and report on vulnerabilities from multiple client tenants.
Each client tenant operates independently and retains full control of its ingestion, enrichment, remediation, and reporting flows. The central tenant receives selective recordsβsuch as work items based on Vulnerability Findings, Remediation Items, Cases, or Assets, as well as reporting, βvia webhook synchronization for unified oversight.
This setup allows MSSPs to:
- Maintain multi-tenant isolation
- Perform centralized reporting
- Track performance across clients via shared dashboards
- Avoid operational conflicts between environments
Architecture of MSSP Mode
The MSSP architecture is built on secure, event-driven data sharing between tenants.
Key Roles
- Client Tenant: Executes vulnerability ingestion and enrichment flows. Shares relevant outcomes (for example,work items) with the central tenant. Automates response, syncing with ITSM systems, and case management. Manages assets and findings per client.
- Central Tenant: Collects data across clients and aggregates insights into dashboards and reports. Collects work items from client tenants for review and action to unblock automation on the client tenant side.
Flow Overview
- The client tenant runs ingestion and enrichment workflows, case creation, and remediation item creation
- Once relevant records (for example, Findings, Remediation Items, Cases, or Assets, that are in the "Requires Attention" state, ) are generated, they are sent via webhook to the central tenant.
- The "Requires Attention" state conditions are specific to each application, but generally indicate that missing fields or error statuses are preventing automation from working as expected.
- The central tenant receives and stores these records using the VRM Central Sync playbook.
- Dashboards and reports in the central tenant are updated to reflect client-specific and aggregated views.
This architecture keeps client operations isolated while enabling centralized monitoring.
MSSP Client Onboarding
The central tenant webhook must be set up to receive incoming data from each client tenant.
VRM Central Webhook Configuration
This webhook resides in the central tenant in the VRM - Central Tenant playbook. Values from this webhook will be entered into each client tenant to activate syncing.
Fields
Field | Description |
|---|---|
Username | Username of your choice |
Password | Password of your choice |
Configuration Steps
- In the central tenant, navigate to Playbooks > VRM - Central Tenant.
- Edit the Webhook at the top of the flow, titled Ingest Record from Client.
- Set a Username and Password (these are arbitrary but must match what is entered into each client tenant).
- Copy the webhook URL, this will be entered into each client tenant's assets as well.
- Provide this configurationβs webhook URL and username/password to each client tenant.
In addition, each client tenant must be onboarded by creating and configuring the VRM Client Configuration and VRM Central Sync assets and connecting them to the Central Webhook Endpoint exposed by the central tenant.
Steps
- Deploy the VRM Client Configuration asset in the client tenant.
- Enter the Client_Name and Central_Webhook_URL fields.
- Validate connectivity and authorization (if required).
- Ensure ingestion and enrichment flows are running before syncing records.
VRM Client Configuration Asset
This asset exists in each client tenant and defines how data should be sent to the central tenant.
Fields
Field | Description |
|---|---|
Client_Name | Unique name for the client (for example, ACME Networks) |
Central_Webhook_URL | The endpoint in the central tenant to receive data |
Configuration Steps
- In each client tenant, navigate to Assets > VRM Client Configuration.
- Enter Client_Name.
- Enter the valid Central_Webhook_URL provided by the central tenant.
- Save the configuration.
VRM Central Sync Asset
This asset exists in each client tenant and defines how data should be sent to the central tenant.
Fields
Field | Description |
|---|---|
Username | Central Tenant Webhook Username (must match) |
Password | The edpoint in the central tenant to receive data |
Configuration Steps
- In each client tenant, navigate to Assets > VRM Central Sync.
- Enter Username and Password.
- Save the configuration.
All outgoing records are routed through this configuration.
MSSP Dashboards and Reporting
In the Central Tenant
VRM - Central Tenant Work Items Dashboard:
- Work items grouped by client
- MTTR trends across clients
- Application heatmaps
- Requires Attention summaries
VRM - Reporting (Central View):
- Aggregated findings by risk score
- Remediation status across tenants
- Top remediation channels and owners
- Exception growth trends
- Asset risk overview
VRM Reporting Information (Central Record View):
- Report Type, Span, Timestamp
- Count of items
- Findings by metric (MTTR, Status, etc.)
- Client identifiers per record (in synced views)
VRM - Work Item (Central Tenant View):
- Centralized listing of synced work items from client tenants
- Tracking ID, Client Name, Client Application, Record Status
- Timestamps for first created and last updated
- Inline metadata: criticality, turbine risk score, and URLs
- Types include Findings (VFIN), Assets (VAST), Cases (VRSP), and Remediation Items (VRI)
In the Client Tenant
VRM - Reporting (Client View):
- All standard VRM dashboards
- Scoped to tenant-specific records only
- Visuals include exception counts, remediation status, ingestion volume, and trendlines
VRM Reporting Information (Client Record View):
- Report Type (for example, Findings, Exceptions)
- Client-specific timestamped reports
- Owner and remediation channel values per record
- Metrics include MTTR and Finding Status
No cross-tenant data is visible in client tenants.
Reporting Metadata
VRM Reporting records (VRPT) store structured information that supports centralized and client-level dashboards, filtering, and auditing.
Client Tenant Reporting Fields
Each client tenantβs VRPT record includes:
Field | Description |
|---|---|
Client Name | Identifier for the tenant (automatically mapped to central) |
Report Type | Type of report (for example, Findings, Remediation Items, Exceptions) |
Report Span | Scope of data: Total or New since last report |
Timestamp | When the report was generated |
Count | Number of records or findings in the report |
Remediation Owner | Email or user responsible for remediation tasks |
Remediation Channel | (Optional) Channel used for tracking (for example, Email, Jira) |
Finding Status | Metric breakdown based on vulnerability state (for example, Open) |
MTTR | Mean Time to Remediate for the included records |
Central Tenant Reporting Fields
On the central tenant side, VRPT records appear with aggregated or forwarded metadata and may have slightly fewer populated fields depending on sync settings:
Field | Description |
|---|---|
Report Type | Copied from the client (for example, Findings, Exceptions) |
Report Span | Copied from the client (for example, Total, New) |
Timestamp | Time of sync or original timestamp |
Count | Forwarded count of findings/remediation items |
Turbine Risk Score | Risk score applied centrally (optional, based on enrichment) |
Remediation Owner | Forwarded owner name or mapped account |
Finding Status | Finding breakdown summary |
MTTR | Included if calculated on client side or recomputed centrally |
Records synced from clients are visible to central analysts without altering original metadata. This supports trusted reporting while preserving source context.
Central Tenant Work Item Reporting Fields
This table describes the metadata fields populated in VRM - Work Item records as seen in the Central Tenant. These records are synced from client tenants and used for centralized investigation and action.
Field | Description |
|---|---|
Current Owner | Assigned analyst or team responsible for the work item |
Criticality | Severity label of the item (for example, High, Medium, Low) |
Status | Status of the record (for example, New, In Progress, Closed) |
Client Name | Identifier of the source tenant (for example, "Client") |
Client Application Name | Application type such as Finding, Asset, Remediation Item, or Case |
Client Record Tracking ID | Original record ID from client tenant (for example, VAST-201, VFIN-1252) |
Client Record URL | Hyperlinked reference to the original client record.Β Click here to visit the client record and resolve the "Requires Attention" status. |
Client Record Status | Current state of the client-side record (for example, New, Requires Attention, Closed) |
Turbine Risk Score | Numerical risk score, if client record has a Turbine Risk Score |
Turbine Risk Score Label | Risk level based on score, if client record has a Turbine Risk Score (for example, High, Medium, None) |
Message | Description or summary associated with the work item |