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 links to related vrm ingestion docs ingestion flow docid\ yqfyivkjd842adc6 asky creating ingestion pages docid 4zov74mieofgknrehuvjq export records and delta training docid\ lb4qwgtwtxybenccyc x5 filtering and deduplication docid\ t2qfi12ilis5utgoclv y monitoring ingestion and enrichment docid\ jfceyuzxvdvxwwgvorlo4