Skip to content

Preview

This guide is a preview. Its content may change.

Planning 2: Decide Your Team and Visibility#

For Everyone

Decide who will use FutureVuls and what each person can see. What you decide here becomes the way you divide groups when you create them on the next page, Setup 1: Structure Your Account.

  • Who this is for

    Administrators

  • Time required

    About 20 minutes

  • What you'll learn

    The six things to decide, and how to think about dividing groups

  • You're done when

    You have decided who will receive accounts, how to divide groups, what each person can see, and where notifications go, and these are recorded in the Onboarding Preparation Sheet

Six Things to Decide#

# What to decide Examples Where to record it in the Onboarding Preparation Sheet
1 The person who leads operations and the person who makes decisions Choose one person to do the daily checks and one person to decide the response policy Operations lead and decision-maker
2 Who will receive accounts List each person's department, name, and role. If anyone needs to see across all groups (such as a company-wide coordinator), list them too Who will receive accounts (B-7)
3 Who you will ask to address vulnerabilities Describe how this is decided today, for example, "Each system has an assigned owner," "It's split by server type," or "It's decided by department" How response owners are decided (B-8)
4 What each department can see "Each department sees only its own servers," "Everyone can see everything," and so on What each department can see (B-9)
5 The tool you use to manage responses Whether you manage responses only with FutureVuls tasks, or also with another tool such as Jira or Redmine How responses are managed (B-10), external ticket management
6 Where notifications go Whether to send them to the assignee for each group or to a single shared mailing list, and whether to send them to Slack or Teams Where notifications go (B-15, C-11)

How to Think About Dividing Groups#

In FutureVuls, a "group" is both the unit of visibility and the unit of daily response work. Based on what you decided in items 3 and 4 above, it's easiest to think it through in the following order.

  1. Divide by what must not be seen: Put servers that other departments shouldn't see into a separate group.
  2. Divide by system: Put the servers that make up the same system into one group. We recommend dividing by system.
  3. When in doubt, use fewer groups: You can split groups later. We recommend starting with fewer groups and splitting them as you go. You can move servers to another group later (Move Server Information to Another Group). Moving a server requires group administrator permissions for both the source and destination groups. In the month you move a server, the server is billed in both the source and destination groups.

If you want to see the status across the whole company or across departments in one place, combine multiple groups into a "group set." Group sets are a CSIRT plan feature (Group Set Settings). A single group can belong to multiple group sets.

flowchart TB
    O["Organization (one per company)"] --> S1["Group set: Production systems"]
    O --> S2["Group set: Public-facing servers"]
    S1 --> G1["Group: IT Systems"]
    S1 --> G2["Group: Production Management"]
    S1 --> G3["Group: Public Web"]
    S2 -.-> G3

If You Manage Responses with Another Tool#

If you manage vulnerability responses in a tool such as Jira or Redmine, decide up front which tool manages what, so you don't end up tracking the same work in both that tool and FutureVuls tasks. If you don't update task statuses in FutureVuls, you won't be able to see in FutureVuls whether responses are progressing.

When you use both, the standard approach is to "record detection and decisions (statuses) in FutureVuls, and manage how the work gets done in the external tool." If you at least keep FutureVuls statuses up to date, you can track response status in FutureVuls. To integrate with external tools, you can use the API (FutureVuls API) or CSV reports.

Troubleshooting#

If that doesn't solve the problem, contact us through the support contact form.

Next Page#

Next, check the environment of your target servers. Continue to Planning 3: Check Your Environment.

Go to Planning 3: Check Your Environment