7. Scanning, Enumeration and Vulnerability Analysis

Introduction and Context

Penetration testing is often described as an attempt to identify and exploit weaknesses in an information system. In practice, however, exploitation is only one part of a much broader investigative process. Before a tester can assess whether a weakness is exploitable, the tester must understand what systems exist, which services they expose, how those services are configured, what software versions are in use, and how the discovered conditions relate to the organisation’s business risk. Scanning, enumeration and vulnerability analysis provide this evidential foundation.

Scanning converts an unknown or partially known environment into a technical map. Enumeration adds detail by extracting information from hosts, protocols, applications, directories, identities and configurations. Vulnerability analysis then evaluates whether the discovered attributes represent security weaknesses, how confidently those weaknesses can be established, and which should receive attention first.

These activities are closely related but not identical. A port scan may show that TCP port 443 is open; service enumeration may identify a web server and its version; configuration analysis may reveal weak transport settings; and vulnerability analysis may correlate the result with a relevant CVE, a known exploit, exposure on the public internet and the importance of the affected business service. The final conclusion should not be “the scanner found a vulnerability.” It should be a defensible judgement about exposure, exploitability, impact, confidence and remediation priority.

Because scanning can generate significant network traffic and may interact with fragile systems, it must be performed within an authorised scope. The professional tester balances coverage against safety, speed against accuracy, and technical severity against business context.

Learning Objectives

After completing this chapter, the student should be able to:

1. Distinguish scanning, enumeration, fingerprinting and vulnerability analysis.

2. Design a safe and purposeful host and service discovery process.

3. Explain the difference between TCP, UDP, authenticated and unauthenticated assessment.

4. Interpret scan results and validate findings using independent evidence.

5. Identify common causes of false positives and false negatives.

6. Correlate vulnerabilities with CVEs, CVSS, EPSS and threat intelligence.

7. Prioritise weaknesses using exploitability, exposure, asset criticality and compensating controls.

8. Apply professional, ethical and governance requirements to scanning activities.

From Reachability to Security Meaning

A useful way to understand the assessment process is as a sequence of increasing certainty:

Discovery asks what hosts, addresses and systems are present. Port and service scanning asks which communication endpoints are reachable. Enumeration asks what those endpoints reveal about software, protocols, users, shares, directories, certificates and configurations. Vulnerability analysis asks whether the observed state corresponds to a weakness. Validation and prioritisation ask whether the weakness is real, exploitable and important in the organisation’s context.

The sequence is not strictly linear. Information discovered in one stage often changes the next stage. For example, identifying a domain controller may justify carefully authorised LDAP, Kerberos and SMB enumeration. Discovering a cloud-hosted application may require examination of DNS, certificates, HTTP headers, identity flows and cloud configuration rather than conventional internal port scanning.

A scan result is therefore an observation, not automatically a finding. “SSH is available” is an observation. “SSH permits password authentication from the internet” is a configuration finding. “An internet-facing server runs an outdated SSH implementation affected by a remotely exploitable vulnerability” is a vulnerability claim that requires version confirmation and assessment of exploitability.

Scoping, Rules of Engagement and Evidence Planning

Before technical activity begins, the penetration-testing team should establish the authorised scope. The scope normally identifies IP ranges, domain names, applications, cloud accounts, excluded systems, testing windows, permitted techniques, emergency contacts, data-handling requirements and reporting obligations. A written authorisation protects both the client and the tester by clarifying what constitutes permitted activity.

Rules of engagement should address rate limits, denial-of-service precautions, credential use, social engineering boundaries, production-system restrictions and procedures for handling sensitive information. A vulnerability scanner configured for aggressive checks may create load, trigger account lockouts or alter application state. Consequently, safe defaults and staged testing are essential.

Evidence planning is equally important. A professional assessment preserves command outputs, timestamps, scanner configuration, target lists, screenshots, packet captures where appropriate, request and response samples, version evidence and validation notes. Findings should be reproducible without unnecessarily retaining personal data or secrets. Evidence must support the conclusion while respecting data minimisation principles.

Host Discovery and Attack-Surface Mapping

Host discovery determines which systems respond or appear to be active. Common methods include ICMP echo requests, TCP probes to selected ports, UDP probes, ARP discovery on local networks, DNS resolution, cloud inventory queries, directory-service information and passive sources such as asset inventories and certificate transparency records. No single method is complete. Firewalls may block ICMP, hosts may be configured not to respond to unsolicited traffic, and cloud systems may appear through load balancers or shared infrastructure.

A mature discovery process combines multiple sources and records confidence. An address identified in an approved asset inventory may be considered high-confidence even if it does not respond to a probe. Conversely, an address observed through a third-party search engine may require ownership verification before active testing.

The result should be an attack-surface inventory containing, at minimum, the asset identifier, address or hostname, environment, owner, exposure, discovery source, time observed and validation status. Asset identity matters because one physical or virtual system may have several addresses, and one address may represent a load-balanced service rather than a single host.

Network and Transport Considerations

TCP scanning commonly uses connection attempts or half-open techniques to determine whether a port is open, closed or filtered. A response indicating that a service is listening is different from evidence that the service is usable or securely configured. UDP scanning is more difficult because open services may not respond to empty probes, and filtered traffic can resemble silence. UDP results therefore often require protocol-specific probes and cautious interpretation.

IPv6 deserves explicit consideration. Organisations may secure IPv4 perimeter ranges while overlooking IPv6 addresses, dual-stack services or IPv6 management interfaces. Similarly, segmentation controls should be tested from relevant network positions rather than inferred from a single vantage point. A service unreachable from the internet may still be exposed to an untrusted partner network, a workstation segment or a compromised cloud workload.

Scanning speed is a technical and operational decision. High parallelism can shorten an engagement but increase packet loss, trigger intrusion-prevention controls and affect fragile devices. Slower, targeted scans often produce more reliable results in production environments.

Service Identification and Enumeration

Service identification maps an open endpoint to an actual protocol and implementation. Port numbers are only conventions; a web service may operate on a non-standard port, and a service may deliberately imitate another protocol. Banner grabbing, protocol negotiation, TLS certificate inspection, HTTP response analysis and application-layer probes help establish service identity.

Enumeration seeks more detailed information. Depending on the protocol and authorisation, it may reveal:

• Operating-system and platform characteristics.
• Product names, versions and build numbers.
• Virtual hosts, directories, files and application routes.
• TLS versions, certificates, cipher suites and certificate names.
• SMB shares, domain information and accessible resources.
• LDAP naming contexts, directory objects or authentication behaviour.
• DNS records, zone-transfer behaviour and delegated namespaces.
• Database listeners, authentication methods and metadata.
• Cloud storage permissions, exposed management interfaces and identity roles.

Enumeration should be purposeful. Collecting every available detail increases noise and may create privacy or safety concerns. The tester should select probes that answer an assessment question. For example, if the objective is to determine whether an administrative interface is exposed, directory discovery and authentication-flow analysis may be more relevant than broad content crawling.

Authenticated enumeration is often more accurate than unauthenticated testing. A scanner operating with approved, least-privileged credentials can inspect installed packages, local configurations, patch levels, security policies and vulnerable libraries that cannot be inferred reliably from network banners. Unauthenticated scanning remains valuable because it represents the perspective of an external attacker, but it may miss weaknesses hidden behind authentication or incorrectly classify patched systems.

Vulnerability Scanning and Vulnerability Analysis

Vulnerability scanning uses signatures, version comparisons, configuration checks, protocol tests and sometimes safe proof-of-concept requests to identify possible weaknesses. A scanner may report missing patches, insecure defaults, weak cryptographic settings, exposed services, vulnerable web components, unsupported software or policy violations.

Vulnerability analysis goes beyond running a tool. It involves examining the evidence, understanding the detection method, confirming affected versions, considering environmental conditions and determining whether the weakness is exploitable. The analyst should ask:

1. What exactly was observed?

2. How did the tool infer the vulnerability?

3. Is the product and version identification reliable?

4. Is the vulnerable feature enabled and reachable?

5. Are prerequisites such as authentication, user interaction or special configuration present?

6. Is exploitation technically feasible from the tested position?

7. What asset, data or business process could be affected?

8. Are compensating controls present?

9. What evidence would confirm or reject the finding?

A scanner may identify a vulnerable library based on a package version even when the vendor has backported a security fix without changing the upstream version string. Conversely, a clean scan may not prove that a system is secure: credentials may be unavailable, a plugin may lack coverage, a vulnerability may be too new for the scanner’s database, or a control may fail only under a particular application workflow.

Models for Interpreting Severity and Priority

CVE and Vulnerability Identification

The Common Vulnerabilities and Exposures system provides identifiers for publicly documented vulnerabilities. A CVE identifier supports consistent reference, but it does not by itself communicate the complete risk of a particular deployment. The same CVE may affect an internet-facing payment service, an isolated laboratory system or a redundant development host with very different consequences.

CVSS

The Common Vulnerability Scoring System expresses technical severity through a structured score. Its base metrics include characteristics such as attack vector, attack complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact and availability impact. Temporal and environmental considerations can refine the assessment.

CVSS is valuable for consistency and communication, but it should not be treated as a business-priority ranking. A high CVSS score on an isolated asset may be less urgent than a medium-scored weakness that exposes a critical identity system. Environmental scoring and organisational context help bridge this gap.

EPSS

The Exploit Prediction Scoring System estimates the probability that a vulnerability will be exploited in the wild within a defined period. EPSS is a probabilistic indicator, not a guarantee. A low EPSS value does not mean exploitation is impossible, and a high value does not prove that a particular organisation is being targeted. EPSS becomes more useful when combined with exposure, asset value, exploit availability and threat intelligence.

Threat Intelligence and Active Exploitation

Threat intelligence may include evidence of exploitation campaigns, ransomware activity, exploit code, attacker targeting, affected technologies and sector-specific threats. Known exploitation in the wild should generally increase urgency, particularly where the vulnerable service is externally accessible. Analysts should distinguish reliable, dated intelligence from unsupported claims and should record the source and confidence of the intelligence.

A Contextual Priority Model

A practical prioritisation model can combine several dimensions:

Priority = technical severity × exploitability × exposure × business criticality × threat relevance, adjusted downward where effective compensating controls reduce practical risk.

This is not a mathematically universal formula; it is a decision framework. Organisations may classify findings as critical, high, medium or low using explicit thresholds. The important point is transparency: two analysts should be able to understand why one finding was remediated before another.

False Positives, False Negatives and Validation

A false positive occurs when a tool reports a vulnerability that is not actually present or not exploitable under the tested conditions. Common causes include inaccurate banners, virtual patching, vendor backports, inactive modules, incorrect asset attribution, stale scanner data and environmental assumptions.

A false negative occurs when a real weakness is not detected. Causes include incomplete credentials, unsupported technologies, blocked probes, rate limiting, encrypted traffic, unusual application workflows, newly disclosed vulnerabilities and reliance on version numbers alone. False negatives are especially concerning because a clean report may create unjustified confidence.

Validation should be proportionate to risk. Low-impact configuration findings may be confirmed through a configuration query or manual inspection. A serious remote-code-execution claim may require version evidence, a safe non-destructive check and confirmation that the affected service is reachable. Exploitation should not be performed merely to make a report more convincing, particularly on production systems.

A useful validation record contains the target, timestamp, detection logic, observed evidence, test limitations, confirmation method, result and residual uncertainty. If a finding cannot be confirmed, it should be reported as suspected or requiring further review rather than stated as fact.

An Operational Workflow for Assessment Teams

A disciplined workflow commonly follows these stages:

Preparation: confirm scope, authorisation, contacts, credentials, exclusions, safety limits and reporting requirements.

Passive and inventory-based discovery: review approved asset inventories, DNS, certificates, cloud resources, architecture diagrams and prior findings.

Controlled active discovery: identify reachable hosts and services from each relevant network position, using conservative rates.

Enumeration: identify technologies, versions, configurations, trust relationships and application functionality.

Credentialed assessment: where authorised, use least-privileged credentials to improve patch and configuration accuracy.

Vulnerability analysis: run appropriate scanners, inspect plugin logic and map observations to vulnerability records.

Validation: confirm significant findings, investigate contradictions and document limitations.

Prioritisation: incorporate CVSS, EPSS, threat intelligence, asset criticality, exposure, exploit prerequisites and controls.

Reporting and remediation support: communicate evidence, impact, priority, remediation options and residual risk.

Reassessment: verify fixes and ensure that remediation did not introduce replacement weaknesses.

Automation can support repeated discovery, asset correlation, scanner scheduling, ticket creation and remediation verification. It should not replace judgement. Automated workflows must include approval gates, rate controls, secrets management, exception handling and logging.

Applied Case: Prioritising an Internet-Facing Vulnerability

Background

This illustrative case concerns Meridian Health Services, a fictional organisation operating clinics, a patient portal and internal identity services. Its security team commissions an authorised external and internal assessment after consolidating several regional networks.

Situation

External discovery identifies four public hosts: a patient portal, a remote-access gateway, a mail relay and a legacy document-transfer service. The scanner reports a high-severity vulnerability against the document-transfer service and a medium-severity TLS configuration issue on the portal. An internal authenticated scan identifies an outdated library on a domain controller, but the scanner cannot determine whether the vendor has backported the security fix.

Analysis

The document-transfer service has a confirmed product version, is reachable from the internet and has publicly available exploitation evidence. Its CVSS score is high and its EPSS estimate is also elevated. The service stores files exchanged with external partners but is isolated from the clinical network by firewall rules. The portal’s TLS issue affects configuration quality but does not permit direct compromise under the tested conditions. The domain-controller finding has potentially severe impact, but package evidence is ambiguous and the system is accessible only from a restricted internal segment.

The team validates the document-transfer finding using a safe version and feature check, confirms that the relevant module is enabled, and verifies that the firewall permits the affected protocol. For the domain controller, administrators provide vendor advisory evidence showing that the security fix was backported even though the displayed version remains unchanged. The scanner finding is therefore classified as a false positive, with the validation evidence retained.

Strategy and Outcome

Meridian first removes the document-transfer service from public exposure, restricts partner access through an approved secure channel and schedules an emergency update. It then reviews stored files and authentication logs for signs of compromise. The TLS issue is placed in a planned hardening workstream. The domain-controller finding is closed as a false positive but the team improves the scanner’s credentialed checks and documents the vendor’s versioning practice.

Learning Points

The case demonstrates that severity scores do not replace analysis. External exposure, exploit intelligence and business function made the document-transfer issue urgent. The domain controller had greater potential impact but required evidence-based validation before escalation. The medium TLS weakness remained worthwhile but did not deserve the same immediate response. Most importantly, prioritisation combined technical data with reachability, asset value, threat evidence and confidence.

Challenges, Limitations and Common Mistakes

Scanning large environments creates problems of scale, ownership and data quality. Duplicate assets, stale DNS records, short-lived cloud workloads and unmanaged devices can make inventory incomplete. Scanner results may also become difficult to interpret when different tools use inconsistent names, severity scales or plugin logic.

Common mistakes include scanning without a clear objective, using aggressive settings against production systems, assuming that closed ports imply a secure host, treating banners as proof of vulnerable versions, ignoring UDP and IPv6, failing to test from multiple trust zones, and reporting every scanner item without validation. Another mistake is concentrating on CVSS while ignoring internet exposure, exploit activity and business dependency.

Credential management presents additional risk. Shared administrator credentials, excessive permissions and credentials stored in scripts can create a greater security problem than the original assessment sought to identify. Testing accounts should be controlled, monitored and revoked after use.

Technical limitations should be stated openly. A scan performed without credentials is not equivalent to a patch audit. A web crawler that does not authenticate cannot assess functions behind login. A network scan cannot establish that an application’s business logic is correct. Transparent limitations improve the credibility of the assessment.

Ethical, Governance and Professional Considerations

Authorised scanning is an exercise of delegated power. Testers must respect scope, confidentiality, privacy, availability and applicable law. They should collect only information necessary for the assessment, protect evidence, avoid unnecessary access to personal data and report accidental exposure through the agreed channel.

Findings should be communicated responsibly. A report should distinguish confirmed vulnerabilities, suspected weaknesses, observations and recommendations. It should avoid sensational language and should not disclose exploitable detail beyond what the client needs for remediation, unless disclosure is governed by a specific professional or regulatory process.

Organisations should connect scanning to governance processes such as asset management, patch management, change control, vulnerability exceptions, risk acceptance and incident response. A formally accepted exception should have an owner, rationale, compensating controls, review date and expiry conditions. Scanning is most valuable when its results lead to accountable decisions rather than an accumulation of unresolved tickets.

Current Developments and Best Practices

Modern environments require assessment approaches that extend beyond traditional data centres. Cloud-native services may be ephemeral, serverless or managed by a provider, shifting attention toward identity permissions, storage exposure, APIs, infrastructure-as-code and control-plane logging. Container images and software dependencies require continuous analysis because the deployed workload may change faster than periodic network scans.

Attack-surface management platforms increasingly combine external discovery, certificate data, DNS, cloud inventory and vulnerability information. Machine learning may assist with asset correlation, anomaly detection and prioritisation, but analysts must examine the provenance and confidence of automated conclusions. Generative systems can help summarise findings, yet sensitive scan data must not be submitted to uncontrolled services.

Effective practice includes maintaining an authoritative asset inventory, scanning from appropriate network perspectives, using authenticated checks where approved, validating high-risk results, recording tool and plugin versions, correlating findings across assets, monitoring exploitation intelligence, assigning remediation ownership and conducting risk-based reassessment. Results should be measured not only by the number of vulnerabilities found but also by remediation time, recurrence, coverage, false-positive rate and reduction in meaningful exposure.

Chapter Summary

Scanning identifies hosts and reachable services; enumeration develops a more detailed understanding of protocols, products, configurations and trust relationships; vulnerability analysis determines whether observed conditions represent genuine weaknesses. Reliable assessment requires clear authorisation, carefully controlled discovery, appropriate use of authenticated and unauthenticated methods, and evidence-based validation.

CVE provides a common vulnerability reference, CVSS expresses technical severity, EPSS estimates exploitation probability, and threat intelligence indicates active or relevant adversary behaviour. None of these measures alone determines business priority. Effective prioritisation combines exploitability, exposure, asset criticality, threat relevance, confidence and compensating controls. False positives and false negatives must be actively managed, and scanner output must be interpreted rather than copied into a report. In professional practice, scanning is part of a governance cycle linking discovery, analysis, remediation, verification and informed risk acceptance.

Key Terms

Attack surface: The collection of reachable systems, services, applications, interfaces and identities that may be exposed to threats.

Authenticated scanning: Assessment performed with authorised credentials to inspect internal software, patches and configurations.

Banner grabbing: Obtaining service or product information from protocol responses or connection behaviour.

CVE: A standard identifier assigned to a publicly documented cybersecurity vulnerability.

CVSS: A framework for expressing the technical severity of a vulnerability through structured metrics.

Enumeration: Systematic extraction of detailed information about hosts, services, applications, users or configurations.

EPSS: A model that estimates the probability of exploitation of a vulnerability in the wild.

False negative: A real weakness that an assessment fails to detect.

False positive: A reported weakness that is absent or not exploitable in the assessed environment.

Fingerprinting: Inferring the identity or characteristics of an operating system, service or application.

Host discovery: The process of identifying systems that exist or respond within an authorised scope.

Network position: The location or trust zone from which an assessment is conducted.

Port scanning: Probing network ports to determine whether they are open, closed or filtered.

Risk prioritisation: Ranking weaknesses according to technical and organisational consequences.

Service identification: Determining which protocol or application operates on a reachable endpoint.

Threat intelligence: Analysed information about threats, adversaries, campaigns, exploitation and affected technologies.

Unauthenticated scanning: Assessment conducted without credentials, representing an external or unauthorised-user perspective.

Vulnerability validation: The process of confirming whether a reported weakness is present and relevant.

Review Questions

Short Answer Questions

1. Distinguish host discovery from service enumeration.

2. Why is a port number insufficient evidence of service identity?

3. What is the purpose of CVE identifiers?

4. State two causes of false positives in vulnerability scanning.

5. Why should scanning speed be controlled in production environments?

Long Answer Questions

1. Explain a complete workflow from authorised discovery through vulnerability prioritisation.

2. Compare authenticated and unauthenticated scanning, including their strengths and limitations.

3. Explain how CVSS, EPSS and threat intelligence contribute different types of evidence.

4. Discuss the methods an analyst can use to validate a high-severity scanner finding.

5. Describe the governance and ethical requirements that should control penetration-testing scans.

Analytical / Application Questions

1. A scanner reports a critical vulnerability on an internet-facing server based only on a product banner, while administrators claim that a vendor backport is installed. Design a validation plan and explain how the finding should be reported if evidence remains uncertain.

2. Two weaknesses are identified: a high-CVSS flaw on an isolated development server and a medium-CVSS authentication weakness on an internet-facing identity gateway. Which should be prioritised, and what additional evidence would you request?

3. An organisation’s external scan finds no vulnerable services, but an internal authenticated scan identifies several missing patches. Analyse why the results differ and recommend a reassessment strategy.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes enumeration from basic port scanning?

A. Enumeration determines whether a host is powered on, while port scanning identifies its owner.

B. Enumeration extracts detailed information about services and configurations after or alongside identifying reachable endpoints.

C. Enumeration is performed only with administrator credentials, while port scanning is always unauthorised.

D. Enumeration measures CVSS scores, while port scanning calculates EPSS probabilities.

Correct Answer: B. Enumeration extracts detailed information about services and configurations after or alongside identifying reachable endpoints.

Question 2

A scanner identifies a vulnerable software version from a banner, but the vendor has applied a backported security fix without changing the displayed version. What is the most appropriate analyst response?

A. Immediately confirm the vulnerability as exploitable because the banner is authoritative.

B. Ignore all scanner results from that vendor permanently.

C. Obtain vendor and configuration evidence and validate whether the vulnerable condition actually exists.

D. Increase the CVSS score because version ambiguity indicates greater risk.

Correct Answer: C. Obtain vendor and configuration evidence and validate whether the vulnerable condition actually exists.

Question 3

Which factor most directly represents EPSS?

A. The technical impact on confidentiality, integrity and availability

B. The estimated likelihood that a vulnerability will be exploited in the wild

C. The number of hosts discovered during a scan

D. The time required to install a security patch

Correct Answer: B. The estimated likelihood that a vulnerability will be exploited in the wild

Question 4

Why can a medium-CVSS vulnerability deserve earlier remediation than a high-CVSS vulnerability?

A. CVSS is never useful for security decisions.

B. The medium vulnerability may have greater exposure, active exploitation or business importance.

C. High-CVSS vulnerabilities are always false positives.

D. Medium findings require no validation.

Correct Answer: B. The medium vulnerability may have greater exposure, active exploitation or business importance.

Question 5

Which result is the strongest example of an observation rather than a complete vulnerability finding?

A. TCP port 443 is reachable and serves an HTTPS response.

B. An exposed service permits unauthorised administrative access.

C. A confirmed vulnerable component is reachable from the internet.

D. A weak authentication configuration allows account takeover.

Correct Answer: A. TCP port 443 is reachable and serves an HTTPS response.

Question 6

What is a principal limitation of unauthenticated vulnerability scanning?

A. It cannot discover any network services.

B. It always causes denial of service.

C. It may be unable to inspect local patch levels and configurations hidden behind authentication.

D. It provides more information than authenticated scanning.

Correct Answer: C. It may be unable to inspect local patch levels and configurations hidden behind authentication.

Question 7

A UDP service does not respond to an empty probe. What is the most defensible conclusion?

A. The service is definitely closed.

B. The host is definitely secure.

C. The result may be ambiguous and may require a protocol-specific probe or other evidence.

D. The service must be vulnerable.

Correct Answer: C. The result may be ambiguous and may require a protocol-specific probe or other evidence.

Question 8

Which practice best reduces the risk of operational disruption during scanning?

A. Use maximum parallelism against all production systems.

B. Scan only during an incident without prior approval.

C. Apply scope-based rate limits, exclusions and staged testing.

D. Disable monitoring so defensive tools cannot react.

Correct Answer: C. Apply scope-based rate limits, exclusions and staged testing.

Question 9

A finding has a high technical score but affects an isolated laboratory host with no sensitive data. Which prioritisation principle applies?

A. Technical score should be copied directly into the remediation order.

B. Business criticality and exposure should be considered alongside technical severity.

C. The finding should automatically be closed.

D. EPSS is irrelevant to prioritisation.

Correct Answer: B. Business criticality and exposure should be considered alongside technical severity.

Question 10

What is the main professional purpose of retaining validation evidence?

A. To make reports longer regardless of accuracy.

B. To support reproducibility, justify conclusions and distinguish confirmed findings from assumptions.

C. To disclose client information publicly.

D. To replace the need for authorisation.

Correct Answer: B. To support reproducibility, justify conclusions and distinguish confirmed findings from assumptions.