Security in depth · Unit 18
Reconnaissance: building an evidence-based map
Turn names, service observations, and inventory records into a useful map without mistaking clues for conclusions.
ATT&CK TA0043 Reconnaissance
Helpful before thisComputers and networksLearn with care: permission, people, and AI
After this lesson you can
- Interpret service observations with their method, location, and time.
- Distinguish a discovered name from confirmed ownership and authorized scope.
- Record evidence, uncertainty, and a sensible next review question.
Lessons in this unit
Browse 8 lessons in this topic
- Inventory starts with a decisionChoose inventory fields that let a responsible team make a maintenance decision.3 min
- Scope has inclusions and exclusionsMatch assets, activities, timing, and exclusions to a written review agreement.3 min
- Keep observations attached to sourcesPreserve source relationships so copied observations do not look like independent confirmation.3 min
- DNS answers are time-bound evidenceInterpret resolver timing and caching without turning a DNS answer into an ownership claim.3 min
- A banner is a clue, not a verdictConnect a reported version to the distributor’s fix record and the software actually running.3 min
- Ownership changes over timeKeep proposed ownership transfers separate from accepted operational responsibility.3 min
- Exposure is a property to verifyDescribe reachability using the observed path and layer, with untested contexts left unknown.3 min
- Separate unknown from absentApply explicit evidence rules to fresh, stale, and retired inventory records.4 min
Imagine taking over support for a community centre. There is a booking website, a staff network, and a supplier-managed payment service. Before recommending protections, you need to understand what exists and who is responsible for it. Reconnaissance is the information-gathering part of that work.
A good map is useful because it is honest about uncertainty. “This name appeared in an old certificate” and “this is a current service we manage” are different claims. This lesson teaches that distinction using fictional records; no scanning software is needed.
Start with the question and the boundary
An assessment needs a purpose, authorized assets, permitted methods, and an agreed time window. Scope may include names, accounts, applications, or environments; it is not always an IP range. A shared cloud address can serve several unrelated customers.
Existing inventories, architecture diagrams, owner interviews, and public records can all contribute. Information available to read does not automatically authorize deeper interaction. Similarly, a newly discovered name does not expand the assessment’s scope.
Every observation has a viewpoint
A vantage point is where and how you looked. A service might be reachable from staff Wi-Fi but unavailable from the internet. IPv4 and IPv6 can have different paths and controls. Results also change with deployment, time, and the observation method.
Service tools summarize responses into labels. These describe the observation, not a permanent property of the asset:
| Label in a fictional service report | Supported interpretation |
|---|---|
| Open | The method observed evidence of a listening service. |
| Closed | The method observed evidence that the port was reachable but had no listener. |
| Filtered | Filtering prevented a decision about whether a listener existed. |
| Open or filtered | The evidence did not distinguish those possibilities. |
Silence alone can have several explanations. A device that does not answer one kind of reachability message can still offer other services. Keep transport, viewpoint, timestamp, and method beside the result; “open” is not a synonym for vulnerable.
Names and versions are clues
DNS records connect names with other information, but do not establish all of an organization’s assets. Certificate Transparency records certificate-related events; an old entry can outlive the service it once described. Neither source alone establishes current ownership, permission, or availability.
A banner is text a service presents about itself. It can be incomplete, customized, or generated by an intermediary. A displayed version may omit a vendor’s backported security fix. Corroborate relevant claims with owner-confirmed configuration, package information, and the applicable vendor advisory.
The name and address both matter for web services: several sites can share an address and respond differently to the requested hostname. Record that relationship without treating every neighbour on shared infrastructure as part of the same organization.
Assessment is more than a list of alerts
Vulnerability assessment can combine configuration review, authenticated inventory, automated checks, and human analysis. Some evidence directly confirms a weakness; other results are leads needing validation.
A confirmed missing required control can support a finding without demonstrating additional harm. A scanner’s severity label, however, does not establish every claimed consequence. Compare its reasoning with the actual asset, build, and configuration.
Keep a map another person can use
Record asset, owner, source, time, viewpoint, supported claim, confidence, and unanswered question. Explicit coverage matters: “IPv6 not assessed” describes a limit; it does not imply IPv6 is absent or unsafe.
Even read-oriented requests can create logs, consume resources, or trigger poorly designed application behavior. “We only looked” is not a complete description of method or effects. A careful handoff says what was reviewed, what remains uncertain, and which owner can resolve it.
EXPLORE THE CONCEPT
How strong is this clue?
Review a fictional record and compare the claim it supports with the claim it does not.
Old certificate name
The historical record supports that the name appeared in certificate-related data. Current ownership, a live service, and assessment scope still need confirmation.
Filtered service result
The method could not determine whether a listener existed because of filtering. It does not establish the software behind the boundary or a vulnerability.
Owner-confirmed configuration
A current, scoped configuration can provide stronger evidence about a control. Record its source and date, then compare it with the relevant requirement.
A simplified learning model. It connects to no systems and uses no real data.
Terms you met
Check yourself
No timer. No penalties. Read the explanation and try again whenever you like.
This lesson’s questions have changed. Your reading progress is saved; review the updated questions.
-
A two-year-old certificate contains a new name. What does that establish?
Show the answer
Correct answer: The name appears in that historical certificate record. That is the supported observation; present ownership and availability require more context.
-
What does a filtered service result mean?
Show the answer
Correct answer: Filtering prevented a determination about a listener. This preserves the uncertainty described by the observation method.
-
Why might a displayed software version be insufficient to confirm a missing fix?
Show the answer
Correct answer: The banner may omit backported fixes or reflect an intermediary. Confirm the relevant package or configuration and vendor advisory.
-
A review did not examine IPv6. How should the map describe it?
Show the answer
Correct answer: IPv6 coverage was not assessed. Recording a gap keeps the map useful without inventing a result.
Try it
- WriteA fictional inventory lists a retired portal; a two-year-old certificate contains its name; today’s owner record says a supplier manages it. Build three rows with source, date, supported claim, and missing evidence. Decide which scope question must be answered before any further assessment.