Three business units, six users, one platform
A holding company runs one Tenable SC instance for three business units. BU-A owns 2,000 IPs in 10.30.0.0/16, BU-B owns 900 IPs in 10.40.0.0/16, and BU-C is a joint venture with 300 IPs in 10.50.0.0/24. Six staff need access: two BU-A security engineers who scan and tune policies only for BU-A; one BU-B analyst who builds dashboards and reports but must not run or modify scans; one external auditor who needs read-only visibility across all three units for a 30-day engagement; a platform administrator who manages the SC appliance itself; and a BU-C contractor who needs to launch four existing weekly scans but must not see BU-A or BU-B data or create new scans.
1. Assign a role to each of the six people and justify the mapping.
Read the worked answer
| Person | Role | Why |
|---|---|---|
| BU-A engineers (2) | Scan Manager | Creates and edits policies and runs scans; can't administer the platform or other users. |
| BU-B analyst | Security Analyst | Analysis, dashboards and reports without scan/policy administration. |
| External auditor | Auditor | Read-only across results and reports; cannot change objects. Time-box the account to the engagement. |
| Platform administrator | Administrator | Appliance, scanners, zones, users, system settings. |
| BU-C contractor | Scan Operator | Launches existing scans only; cannot author policies or new scan definitions. |
Reasoning: pick the least-privileged role that still permits the stated job, then add the second control - scope - because roles alone do not partition data. Two engineers who can "manage scans" company-wide would otherwise be able to target BU-B's ranges. Note the BU-B analyst: the temptation is to give them Scan Operator "just in case"; that grants scan execution they explicitly must not have.
2. Roles do not limit which hosts a user can see or scan. What second control do you apply, and to which groups?
Read the worked answer
Group-level IP restriction. Each group is restricted to the address space of its business unit, so analysis results, scan targets, dashboards, and reports are filtered to that scope regardless of role.
- Group BU-A → restricted to 10.30.0.0/16, containing the two engineers.
- Group BU-B → 10.40.0.0/16, containing the analyst.
- Group BU-C → 10.50.0.0/24, containing the contractor.
- Group Audit → restricted to nothing (full visibility) but holding only the Auditor role.
- Group Platform → the administrator.
Consequences to design around:
- Objects must be shared with the right groups. A scan or dashboard created by BU-A is not automatically visible in BU-B, and vice versa; decide deliberately which objects are shared and which are private.
- The contractor must have the four weekly scans shared to the BU-C group, with those scans targeting only 10.50.0.0/24. Sharing a scan whose targets include other units would leak data even though the restriction exists.
- The auditor's account needs an expiry date; "temporary read-only" is a process control, not a technical one, unless you enforce it.
3. Six months later BU-B reports it can see vulnerability data for 10.30.x hosts on its dashboard. What are the plausible causes and how do you investigate?
Read the worked answer
Treat it as a scoping defect with four candidate causes, in order of likelihood:
- Shared object with wrong target range. A scan or asset list created for BU-A (or by the administrator) was shared to BU-B, and a dashboard component references it. Object sharing crosses group boundaries by design; that is exactly how leakage happens.
- Dashboard component built from an unscoped query. Components created before the group restrictions existed, or by a user with broader scope, may reference an asset list or query that isn't confined to the viewer's range.
- Static asset list containing foreign IPs. A static list isn't validated against the group's restriction at creation time; if it was built by hand, it can contain 10.30.x entries.
- Group restriction changed. Someone widened BU-B's restriction or moved a user between groups during an onboarding.
Investigation order: identify the component and its queries, check the sharing on every object those queries touch, then check the group restriction and its membership. Fix at the object/share layer rather than by widening or narrowing restrictions - restrictions are the last line of defence, not the primary design.