MSSP guidance

View as Markdown

As an MSSP, you can use runZero to extend your current offerings and build new ones for your customers around asset management and asset risk management.

Who is this playbook for and why?

This playbook guides MSSPs through creating and delivering an offering built on the runZero platform. It is deliberately simplified: a starting point for you to adapt to your needs rather than a complete offering.

How will runZero help?

Four success outcomes and their key results

Total attack surface visibility

Additional resources

Full-spectrum exposure detection

Additional resources

Risk prioritization and insights

Additional resources

Compliance, reporting, and KPIs

Additional resources

What will I need to do?

The high-level steps:

  1. Define your offerings.
  2. Build your per-offering project plan.
  3. Identify customers that would be interested in the offerings.
  4. Deliver the offerings.

Implementation steps

The three steps below take you from defining your offerings to building deployment plans.

Step 1: Define your offerings

You will likely want to build your offerings around runZero’s core use cases.

Reduce gaps in asset visibility

Current customer challenges:

  • Tracking assets by hand, with spreadsheets and scripts.
  • Relying on a small group of employees whose departure would devastate the program.
  • Struggling to track rogue IoT and OT devices.
  • Migrating to the cloud or remote work, and losing visibility between on-premises, cloud, and remote assets.

Key results:

  • Scan all assets in days rather than weeks.
  • Integrate with all cloud providers and other relevant tools.

Reduce investigation times

Current customer challenges:

  • No single source of truth for assets.
  • Alerts keep arriving for assets that are not in the current inventory.
  • Searching and analyzing assets in a hand-built inventory is hard.

Key results:

  • Find any asset in your environment in seconds.
  • Review all services an asset runs in minutes.
  • Understand potential exposure to new vulnerabilities.

Reduce asset risk

Current customer challenges:

  • Unable to respond to vulnerabilities without a complete inventory.
  • Unable to confirm endpoint protection deployment or vulnerability scan coverage.
  • Unable to identify misconfigurations in the environment at scale.

Key results:

  • Eliminate misconfigurations.
  • Reduce gaps in endpoint protection.
  • Reduce gaps in vulnerability scanning.
  • Eliminate unmanaged assets through onboarding or retirement.
  • Discover unauthorized assets to be removed.

Step 2: Structure your runZero environment for multiple customers

Decide how to structure your runZero tenant for many customers before you start. A few choices made ahead of time make delivery smoother.

Tenancy

You can choose between two tenancy models: an account per customer, or a single global account. Each has pros and cons.

Per-customer account

Each customer creates their own runZero account and manages the runZero billing themselves. You hold a separate contract with them for the services you layer on top. You could also still be a runZero partner and keep the runZero billing on your paperwork.

Pros:

  • Each customer can use SSO.
  • Customers have access to global settings like user management, queries, and alerts.

Cons:

  • Licensing is per account.

Global account

You run a single runZero account and manage all of the customers yourself. Your runZero asset count grows with your customer base.

Pros:

  • You can make global changes to all customers’ queries and alerts.
  • A simpler customer experience.

Cons:

  • No per-customer SSO.

Self-hosting

You and your customers can also self-host runZero. The per-customer and global account models still apply, but reaching a self-hosted instance takes some configuration because it will likely sit on a private network. Deploying the instance in the cloud can simplify access.

Pros:

  • Data stays in your environment, if you have requirements around that.

Cons:

  • Access to the runZero console gets more complicated.

Organizations

Organizations are at the heart of RBAC in runZero. With the global account model, you create a new organization for each customer to keep data access separate. With per-customer accounts, each customer likely has a single organization, apart from edge cases that need further access controls.

If a customer needs more granular RBAC, parent-child relationships between organizations provide it: you can then grant access to the customer’s parent organization or to a specific child organization.

A sample structure could look like this:

  • Customer A
  • Customer B
    • Customer B1
  • Customer C
    • Customer C1
    • Customer C2
  • Customer D

Customer access to organizations

Your options for user access depend on the tenancy model.

Per-customer account tenancy

  • SSO: Configure SSO, optionally with group mappings, to allow user access.
  • Username and password: Require users to sign in with their registration email and a password.

Global account tenancy

  • User by user: Give each invited user specific access to their organization(s).
  • Groups: Create a group for each customer and add each invited user to the group that has access to their organization(s).

Your access to organizations

Your own access also depends on the tenancy model.

Per-customer account tenancy

  • External users: Customers invite you to their account as an external user.

Global account tenancy

  • Global access: Give your team a default role with access to every organization.

    • Pro: simplified authentication for you
    • Con: potential for accidental updates to the wrong customer

  • Organization-based access: Use a custom email per customer to sign in to each account with the proper permissions.

    • Pro: reduced risk of making a change on the wrong customer
    • Con: more authentication to manage

Sites

We strongly recommend a single site per customer unless IP space overlaps. With less site-based context to keep track of, your investigations across accounts get simpler.

Credentials

Administrators can create credentials for any organization they have access to. If you have access to several customer organizations, take care when you create a credential and confirm it is available only in the correct organization.

Custom integrations

Custom integrations are also scoped to organizations, so grant an integration only to the customer organizations that should be able to run it. Only a superuser or a user whose default role is Administrator can edit an integration made available to every organization, which makes that scope a good fit for an integration you maintain across all of your customers.

Queries and alerts

Only superusers can create new queries and alerts in runZero, so set up a process for customers to submit query and alert requests. You can still push queries and alerts out globally, so you don’t need to replicate them.

Step 3: Build your per-offering deployment plans

We have documented a complete deployment plan, but your customer engagements are narrower in scope, so condense it for each offering. Start from these four templates and customize them.

  • Customer onboarding
  • Reduce gaps in asset visibility
  • Reduce investigation times
  • Reduce asset risk

Customer onboarding

Reduce gaps in asset visibility

Reduce investigation times

Reduce asset risk

Getting help

For help building out this process, book a session with a runZero Customer Success Engineer.

Updated