Knowing what you have before you scan it

Why this matters

Every vulnerability metric you will ever produce has a denominator, and the denominator is the asset inventory. "We have remediated 94% of critical findings" means nothing if the 6% is measured against a list that omits a third of the estate.

Lesson 3 made this point for detection: coverage gaps are invisible from inside the tool. It is exactly as true for vulnerability management, and it is worse, because the reporting in Domain 4 will present those numbers to people who make decisions with them.

An unknown asset is not an unscanned asset. It is an asset whose risk is unmeasured and unowned.

The lesson

Active and passive discovery

Discovery is the process of finding what exists, and it needs more than one method because each finds different things.

Active discovery sends traffic: ping sweeps, port scans across ranges, service probes. It is fast and thorough for what is switched on and reachable, and it misses hosts that are off, firewalled, or on a segment the scanner cannot reach.

Passive discovery watches traffic, per lesson 17. It finds anything that communicates, including devices that would never answer a probe, and it finds them continuously.

Authoritative sources are the third category and the most under-used:

• DHCP leases — anything that got an address, whether or not it answers.
• DNS records, internal and external.
• Directory objects: computer accounts in Active Directory.
• Cloud provider APIs, which will enumerate every instance, function, bucket and database across every subscription.
• Endpoint management and EDR consoles, listing every managed device.
• Switch and router tables: ARP caches and MAC address tables show what is physically connected.
• Certificate transparency logs, which reveal externally-facing names you may not have registered anywhere internally.

The method that actually works is correlation between sources, and the finding is usually the difference. A host in DHCP but not in the EDR console is an unmanaged device. A cloud instance with no owner tag is unowned. A DNS record pointing at an address you no longer control is a subdomain takeover risk.

None of those is visible from any single source, which is the whole argument for doing this deliberately rather than trusting one console.

Shadow IT and the assets nobody told you about

Shadow IT is everything procured, built or deployed outside the process that would have registered it.

Where it comes from, in roughly descending order of frequency:

• Cloud accounts opened on a credit card by a team that needed something quickly.
• SaaS subscriptions, often free tiers, holding real company data.
• Development and test environments built "temporarily", which become permanent and are exempt from every control because they were never meant to last.
• Contractor and third-party systems connected to your network.
• Acquisitions, which arrive as an entire estate you have never scanned.
• Personal devices, where policy allows or does not enforce.
• Forgotten infrastructure: the server nobody decommissioned, the domain nobody renewed attention to, the load balancer rule pointing at a dead instance.

Why it is disproportionately dangerous: these assets miss patching, miss monitoring, miss backup, and frequently run outdated software — and because nobody remembers them, nobody notices when they are compromised. A substantial share of real breaches begin on a system the security team did not know existed.

Finding it:

• External attack surface discovery from the internet, starting from your domains and address ranges rather than your asset list. This is the single most productive exercise available, because it looks the way an attacker looks.
• Certificate transparency monitoring for new names under your domains.
• Cloud organisation-level enumeration rather than per-subscription, so accounts opened outside the main structure appear.
• Expense and procurement review for recurring cloud and SaaS charges.
• Network correlation, as above.

The cultural half matters too. If registering an asset is slow and painful, people will avoid it, and the inventory will be permanently wrong. Making the sanctioned path the easy path does more for coverage than any scanner.

Ownership: the field that makes a finding actionable

A finding without an owner cannot be remediated, only reported. This is the field that most often decides whether a vulnerability programme achieves anything.

What ownership needs to record:

• A named technical owner — the person or team who can actually change the system. Not a distribution list nobody reads.
• A business owner who can accept risk or authorise downtime, since the analyst cannot, per lesson 1.
• An escalation path for when the technical owner does not respond.
• A review date, because people change roles and a stale owner is close to no owner.

Without it the predictable failure occurs: a critical finding is raised, assigned to a generic queue, bounced between teams who each believe it belongs to another, and is still open ninety days later with everyone having behaved reasonably.

Worth noting for the exam: ownership is also what makes risk acceptance possible. Someone must be able to say "this will not be fixed, and I accept that", and that person must have the authority to be bound by it. An unaccepted, unremediated finding just sits there accumulating, which satisfies nobody and protects no one.

Cloud assets that exist for nine minutes

Cloud and container environments break the assumptions that traditional inventory was built on.

• Instances live for minutes. Autoscaling creates and destroys constantly, so a weekly scan sees a sample rather than a population.
• Identifiers are reused. Addresses are recycled across tenants; a hostname may refer to different machines on different days.
• Infrastructure is code. The right unit of remediation is often the template, not the instance — patching a running container is pointless when the next deployment recreates it from the same image.
• Serverless has no host at all. A function has code, permissions and dependencies, and nothing to install an agent on.
• Managed services are partly the provider's responsibility, and the split varies by service — the shared responsibility model in concrete terms.

How mature programmes handle it:

• Assess the image and template, before deployment, rather than the instance afterwards. This is the shift-left argument, and in ephemeral environments it is not a preference but a necessity.
• Query the provider API for the current inventory rather than maintaining a separate list. The provider always knows.
• Tag at creation and enforce it — owner, environment, data classification. An untagged resource should be an exception that gets chased.
• Measure by workload rather than host: "this image has this vulnerability and is running in forty places" is the actionable statement.

Why an inventory gap is a vulnerability in itself

The argument to be able to make, because it is the one that gets inventory work funded.

An unknown asset is worse than a known vulnerable one. A known vulnerability has a score, an owner, a remediation path and a deadline. An unknown asset has none of those — and it is also, typically:

• unpatched, because patching follows inventory,
• unmonitored, because agent deployment follows inventory,
• unbacked-up, because backup policy follows inventory,
• and unnoticed when compromised, for all of the above reasons.

It also corrupts every number you report. Coverage percentages, remediation rates and SLA compliance are all computed against the known estate, so an incomplete inventory makes every metric optimistic in direct proportion to how incomplete it is. That is a specific, damaging failure: the reports look better precisely because the problem is invisible.

So the honest way to report it — and this is the link to Domain 4 — is to state coverage alongside every other metric. "94% of critical findings remediated within SLA, across an estate we believe to be 87% discovered" is a sentence that lets a reader weigh it properly. Quoting the first number alone is the kind of true-but-misleading reporting that the last lessons of this course are about avoiding.

Topics this lesson owns

• [x] Active and passive discovery
• [x] Shadow IT and the assets nobody told you about
• [x] Ownership: the field that makes a finding actionable
• [x] Cloud assets that exist for nine minutes
• [x] Why an inventory gap is a vulnerability in itself