Five hundred servers, sixty of them moving
A server team sends a spreadsheet of 500 production servers, which is loaded as a static asset list and used as the scan target for a weekly job. Sixty of those servers are DHCP and change address every few weeks; the spreadsheet is refreshed quarterly at best. Forty production servers live in a DMZ scanned by a different zone and appear in the list by hostname only. Separately, an acquired company's .nessus results were imported into a new offline repository, and several of the acquired hosts share IP ranges with legacy internal hosts. Dashboard "Critical vulnerabilities on production" now reads higher than anyone can reconcile, and the weekly scan reports 41 targets as unreachable.
1. Choose the asset list type(s) for the 500 production servers and justify the choice against the failure modes described.
Read the worked answer
A static list is a snapshot of addresses, and 60 DHCP hosts guarantee it decays. The correct design is layered:
- Dynamic list for the movable majority. Build it on stable identity - DNS name, NetBIOS name, or a combination of hostname pattern and observed service - so re-addressing doesn't orphan a host. Dynamic lists resolve at use time, which is exactly what a weekly scan needs.
- Combination list to union the dynamic production list with any explicitly enumerated ranges that identity-based matching would miss (appliances with no resolvable name, for example).
- Static list only where the membership is genuinely fixed - a small, curated exception set that a human reviews.
Why not just refresh the spreadsheet more often: it converts an automation problem into a human process that already failed once at quarterly cadence. The 41 unreachable targets are the symptom - some are DHCP hosts that moved, some are the DMZ hostnames that the zone's scanner cannot resolve or route to. Verify which is which before changing the list, because an unreachable target can also mean the wrong scan zone was used for the DMZ entries.
2. How do you stop the acquired company's offline data from contaminating production dashboards, given the overlapping IP ranges?
Read the worked answer
Don't try to merge them. Repositories are the boundary, and overlapping IPs make merging actively dangerous: the same address in two repositories describes two different machines, and any IP-keyed filter, asset list, exclusion, or risk rule will cross-apply.
Design:
- Keep the acquisition in its own repository. Never target the same IP space from two repositories that feed one dashboard.
- Build dashboards and reports with an explicit repository scope (or an asset list that is itself repository-scoped). An unscoped component aggregates everything and will double-count.
- Do not use IP-only asset lists for the acquired estate; use identity-based matching (hostname/DNS) so a reused 10.x address doesn't inherit the other company's history.
- If the goal is a single executive number across both, aggregate at the reporting layer - two scoped components, or two report chapters - rather than in one repository, so the provenance stays visible.
Also verify: imported results carry the policy and plugin set of the exporting scanner. Confirm the acquisition used a comparable policy before putting its severity counts next to yours in one chart.
3. The weekly job reports 41 unreachable targets. Walk through your triage, naming what you would check before editing the list.
Read the worked answer
Unreachable targets are evidence about reachability, not about list membership. Triage in this order:
- Which zone ran the scan, and which scanner. DMZ hosts scanned from an internal zone will always be unreachable. The 40 DMZ entries should be scanned by the DMZ zone; that alone may explain a large share of the 41.
- Name resolution. Hostname-based entries fail if the scanning scanner can't resolve them. Check resolution from the scanner's network position, not from a workstation.
- Liveness method. If the policy pings with ICMP only, hosts that block echo are declared down and reported much like unreachable. Confirm with a TCP-based probe.
- Genuine decommissioning or address churn. Match the remainder against the DHCP lease data before deletion.
Only after those four do you touch the list. Deleting entries to make the error count go away destroys coverage silently - and if a host is later re-added at a new address, its vulnerability history restarts, which distorts every age and trending metric you report.