T Techclick ← All lessons
Palo Alto · Cortex Xpanse · Interactive lesson

Xpanse see what the internet sees

Ticket: Qualys is clean, CMDB has no 192.0.2.80, helpdesk closed “not ours.” Shodan still shows TCP/3389. Cortex Xpanse already has the service. The product is outside-in: it inventories the internet-facing asset first, then attributes ownership, then tracks remediation. A closed ticket is not a closed port. Lab: public 192.0.2.80:3389 RDP, domain rdp-dev.lab.example, Business Unit missing.

16 min read · L2 primary · Quiz at end

After this page you can

Lessons · Cortex series · External attack surface

This page vs XSOAR and XSIAM ASM

This lesson is Cortex Xpanse Expander: outside-in inventory, attribution, ownership, remediation proof. XSOAR is how you automate the ticket once the owner exists. On Cortex XSIAM Premium (or the ASM add-on) the same objects appear under Inventory / Modules → Attack Surface — the data plane does not change.

XSOAR playbook lifecycle · Palo Alto operational failures

Hero · internet sees the asset; CMDB does not
Public internet scanning exposed IP, domain, certificate and RDP while an internal CMDB stays closed
Mood, not a field list. Exact objects are in the SVG: Xpanse scans the public edge; CMDB is an inside list. The two only meet after attribution.
Quick answer

Xpanse is agentless External Attack Surface Management. It continuously scans the public internet (IPv4 space, multiple times per day), inventories domains, certificates, owned IP ranges, responsive IPs, services and websites attributed to you, then fires Attack Surface Rules into issues. Attribution answers why this is yours (seed term, Registered to You / Has Your Content, Discovered vs Provided). Ownership is the BU tag so a human can close the port. Proof is a later scan: Is Active = No. Lab: 192.0.2.80:3389 RDP, no BU, Azure rg-lab-dev.

Why the CMDB is not the internet

The day-one ticket is always the same: “We don’t own that IP.” Wrong question. Attackers do not query ServiceNow. They scan 0.0.0.0/0. Xpanse does the same scan, then tries to prove the responder belongs to you.

Three silent-open states look identical from the SOC (no CMDB hit, no Qualys agent):

A clean internal scan does not close an internet port

Qualys / Nessus / Prisma need a target list or a cloud connector. Xpanse does not. If the service answers on the public internet, it is in scope whether or not your CMDB, AD, or agent inventory ever heard of it. Do not close “not ours” until you have read Asset Attribution Evidence.

Asset, attribution, finding — three objects

An internet asset is something Xpanse can observe from outside: a domain, a certificate, an owned IPv4/IPv6 range, an owned responsive IP, a cloud compute instance, a website. A service is a domain:port or IP:port pair with classifications (banner, software, missing headers). Services are inventory. They carry no policy verdict.

Attribution is the reason Expander believes the asset is yours. It is not the same as a Business Unit. Attribution is on the asset (domain / cert / IP range), not on the service or website row — click through. Ownership is the BU tag you (or a bulk CSV) apply so remediation has a named org unit.

Path · discover, attribute, assess, assign, rescan
Five glass panels labeled Discover, Attribute, Assess, Assign, Rescan
Feel of the order. Exact objects — seed term, Has Your Content, BU, Attack Surface Rule, Is Active — are in the SVG below. Do not read “Assign” as “the finding is fixed.”

Internet asset

Domain, cert, owned IP range, responsive IP, cloud instance, website. GUI: Asset Inventory (Unified Inventory, Certificates, Domains) and Inventory → Owned IPv4 Ranges.

Service

IP:port / domain:port. Classifications, banners, inferred CVEs. GUI: Asset Inventory → Services. Is Active = observed recently. No security judgment.

Attribution

Origin: Discovered vs Provided. Reason: Registered to You vs Has Your Content. Plus seed-term match. Confidence: Very High / High / Medium.

Finding

Attack Surface Rule → issue / alert. High = known-insecure version or inherently risky internet service (RDP, DB). Most rules are opt-in. Remediation guidance lives on the rule.

Say this out loud

Xpanse sees what the internet sees. Attribution says why it is ours. A finding without a Business Unit is not a fix. Closure is a later scan, not a ticket status.

Discover → attribute → remediate

Scan first. Xpanse indexes the public IPv4 space on hundreds of port/protocol pairs — not just “open ports.” A responder becomes an owned responsive IP when it sits on a range already attributed to you, or when a certificate / domain / cloud connector ties it back. Then a service row appears. Then, if an Attack Surface Rule is enabled and matches, an issue is created. Then a human (or XSOAR) assigns a BU and remediates. Then you wait for the next scan.

Flow 1 · lab 192.0.2.80:3389 RDP
1 Discover 192.0.2.80:3389 2 Attribute Has Your Content 3 Assess RDP rule · High 4 Assign BU Cloud-Dev 5 Rescan Is Active = No Service row is inventory. Issue is the rule. BU is the owner. Discovery Type: Directly Discovered (org cert on 192.0.2.80) · Azure rg-lab-dev Attack Surface Rule: RDP exposed · Severity High · new findings ≤ 24 h after enable Stop at step 2 with empty BU: issue exists, nobody remediates, port stays open. Do not close as false positive because CMDB is empty. Read Asset Attribution Evidence first. Disable a rule → new issues stop. Existing open issues stay open until you change status. Source: Cortex Xpanse — Services; Asset Attribution; Attack Surface Rules.

Read left → right, then the gold bar. The service can exist with no issue if the RDP rule is still disabled. Enable the rule, then hunt the owner.

ObjectLab valueIf missing
Owned responsive IP192.0.2.80 on range 192.0.2.0/24No IP to hang the service on. Check Owned IPv4 Ranges + RIR record.
ServiceRDP 192.0.2.80:3389 · Is Active = YesBanner never observed. Confirm the NSG still allows Internet, then wait a scan cycle.
Domain / certrdp-dev.lab.example · CN matchesAttribution falls back to RIR or cloud connector only — Medium confidence for cloud compute.
AttributionHas Your Content + Discovered · seed “lab.example”Do not treat as Shadow IT until evidence is empty and cloud/RIR are empty.
BUnone → then Cloud-DevIssue has no owner. XSOAR cannot route. Port stays open.
Attack Surface RuleRDP exposed · High · EnabledService sits in inventory forever with no issue. That is not “safe.”
Closure proofIs Active = No after rescanTicket Resolved while 3389 still answers. Attackers do not read Jira.

Xpanse vs scanner vs CMDB

Pick the tool for the question you are actually asking. Mixing them is the usual “Qualys is green so RDP is closed” ticket.

Flow 2 · why this asset is yours
Attribution why Expander says yours Registered to You / Content Discovered vs Provided Business Unit who remediates BU tag on domain / IP range CSV APPEND / REPLACE Attack Surface Rule what is out of policy RDP exposed · High issue, not inventory Very High: range registered to you AND hosts your cert/domain. High: Provided assets, certs, domains. Medium: registration-only ranges (stale WHOIS) or cloud compute (IPs move). Attribution evidence is not on Services/Websites. Colocated with your Services ≠ yours. Same IP as a directly-discovered service; may be a neighbour in multi-tenant hosting. Source: Cortex Xpanse — Asset Attribution; Services (Discovery Type); Bulk BU management.

Three columns, three tickets. Do not use a Qualys agent check to “disprove” a Has Your Content attribution.

NeedUseSkip
What does the internet see on us?Xpanse Asset Inventory → Services / Owned IPv4 RangesCMDB export. It only lists what someone already enrolled.
Is this host patched?Authenticated scanner or Prisma / agent once you have the owner and a private pathTreating an Externally Inferred CVE as a confirmed finding. It is a version match against NVD.
Who remediates?BU tag on the domain or IP range; cloud tags from AWS/Azure/GCP or Prisma CloudMailing “security@” and hoping. Empty BU = no SLA.
Is RDP still on the internet?Wait for the next Xpanse observation; Is Active and Last ObservedClosing the issue the minute NSG is edited. Scan lag is real (new findings after enable: up to 24 h).

Runbook Side A / B / C

Side A is inventory and attribution. Side B is the rule and the owner. Side C is the rescan. Do not start at C, and do not start in XSOAR.

Side A — find the internet-facing asset

  1. Open Services, not the CMDB

    Asset Inventory → Services. Filter Service Type / Port 3389, or Externally Detected Providers = Azure. Lab row: Service Name RDP on 192.0.2.80:3389, Protocol RDP, Is Active = Yes, Discovery Type Directly Discovered. Source: Cortex Xpanse docs — Services.

  2. Read attribution on the parent asset

    Click the IP or domain, not the service. Asset Attribution Evidence: Origin (Discovered / Provided), seed term, scan data that matched. IP ranges also show Attribution Reason Registered to You or Has Your Content. Lab: Has Your Content via cert CN rdp-dev.lab.example. Source: Cortex Xpanse — Asset Attribution.

  3. Confirm the range

    Inventory → Owned IPv4 Ranges. Click 192.0.2.0/24. Registration Record (ARIN/RIPE/…) is updated ~biweekly. Active Owned Responsive IPs Count should include .80.

https://expander.expanse.co/ · Asset Inventory → Services
Training mock · not live

Asset Inventory / Services · filter port = 3389

Services

RDP · 192.0.2.80:3389
Yes
Directly Discovered
Azure
AT:Discovered · BU: —
2026-09-04 18:12 UTC

Training mock. Empty BU on an active RDP service is the whole ticket. Next click: parent IP → Asset Attribution Evidence. Source: Cortex Xpanse — Services.

Side B — rule, owner, remediation

  1. Enable the Attack Surface Rule if it is still opt-in

    Expander: Policies and Rules (XSIAM: Modules → Attack Surface → Policies → Attack Surface Rules). Lab: RDP exposed, default severity High (inherently risky internet service). Most rules start Disabled — enable, then expect new findings within 24 hours. Disabling stops new issues; open ones stay open. Source: Attack Surface Rules.

  2. Assign a Business Unit

    BU cannot be edited on an individual service row. Set it on the domain or IP range. Bulk: Settings → Configurations → Asset Management → BU Management, CSV columns Asset, AssetType, BusinessUnits, ActionType with APPEND or REPLACE. Max 50 rows. Lab: 192.0.2.80 · IP_RANGE · Cloud-Dev · REPLACE. Admin role required; the BU must already exist. Source: Bulk business unit management.

  3. Remediate on the owner’s control plane

    Xpanse does not close Azure NSGs by itself unless you run Active Response / XSOAR playbooks. Lab fix: NSG deny inbound TCP 3389 from Internet, or deallocate the VM in rg-lab-dev. Then leave the issue open until the next observation.

https://expander.expanse.co/ · 192.0.2.80 · Asset Attribution Evidence
Training mock · not live

Asset Inventory / Owned Responsive IPs / 192.0.2.80

Asset Attribution Evidence

Discovered
Has Your Content
Very High (range + cert)
lab.example
Certificate CN=rdp-dev.lab.example on 192.0.2.80:3389
Open range 192.0.2.0/24 Assign BU Cloud-Dev

Training mock. “Not in CMDB” is not a counter-argument to Has Your Content + org cert. Source: Cortex Xpanse — Asset Attribution.

CSV — Side B bulk BU (Settings → Configurations → Asset Management → BU Management) 
Asset,AssetType,BusinessUnits,ActionType
192.0.2.80,IP_RANGE,Cloud-Dev,REPLACE
rdp-dev.lab.example,DOMAIN,Cloud-Dev,APPEND

Side C — prove it on the next scan

  1. Do not resolve yet

    NSG edited ≠ internet closed. Wait for a subsequent observation. New rule findings can take up to 24 hours; service Is Active flips when Xpanse no longer sees the port.

  2. Re-open the service row

    Asset Inventory → Services · same 192.0.2.80:3389. Wanted: Is Active = No, Last Observed frozen at the last positive hit, RDP classification moves to Inactive Classifications. Then set the issue Resolved with that timestamp in the notes.

  3. Optional: XSOAR mirror

    If incidents are mirrored, the Handle Expanse Incident playbook is enrichment + owner hunt, not the scan itself. Pair with XSOAR playbook lifecycle. Do not mark the XSOAR incident closed while the Xpanse service is still Active.

Green is Is Active = No, not a ticket checkbox

Proof fields: service Is Active, Last Observed, issue status, BU = Cloud-Dev. If 3389 still answers from a random VPS, the NSG did not take or you remediated a different NIC. Rescan, do not argue with the banner.

One exposure after go-live

Every new public IP, cert, or domain that matches a seed term lands in inventory on the next global scan. If the matching Attack Surface Rule is enabled, an issue appears. If the parent range already has a BU, the issue is born with an owner. If not, you are back at Side B.

Proof · rescan, then resolve
Operations desk with a monitor showing green closure checks after an exposure rescan
Verification mood. The actual proof is the Services row: Is Active = No after the NSG change, with Last Observed no longer current.

Traps + proof

SymptomLikely causeWhat to check
Helpdesk: “not ours, close it”CMDB empty; attribution ignoredAsset Attribution Evidence. Has Your Content or Registered to You beats a missing CI.
Service exists, no issueAttack Surface Rule still Disabled (default for most rules)Policies → Attack Surface Rules. Enable RDP / DB / known-insecure. Wait ≤ 24 h.
Issue assigned to Security foreverNo BU on the domain or IP rangeBU Management CSV. You cannot set BU on a single service row.
Inferred CVE panicVersion string matched NVD; OS/mitigations unknownHigh vs Medium confidence. Confirm on the host. Xpanse over-matches on purpose.
Ticket Resolved, Shodan still 3389Resolved without a later observationServices → Is Active. If Yes, the port still answers. Re-open.
Looking for attribution on the serviceEvidence is not published on Services or WebsitesOpen the parent IP / domain / cert.
Scanner noise from Xpanse itselfGlobal scan ranges hitting the NGFWAllowlist published Xpanse ranges (CFAA-compliant). Abuse: scaninfo@paloaltonetworks.com.
Pilot checklist — lab 192.0.2.80:3389

Knowledge check

Six judgment items. Map each back to attribution, BU, or rescan — not product slogans.

Q1

Qualys and the CMDB have no record of 192.0.2.80. Xpanse shows RDP on 192.0.2.80:3389. What is Xpanse actually telling you?

Correct: b. Services are the outside-in inventory. A disabled rule only hides the issue; the port is still on the internet. Re-read Why the CMDB is not the internet.
Q2

Helpdesk wants the issue closed as false positive because “nobody owns that VM.” First move?

Correct: a. Attribution is why Expander says it is yours; BU is who remediates. Evidence is not on Services/Websites. Re-read Asset, attribution, finding and Side A.
Q3

What is the difference between Asset Inventory → Services and an Attack Surface Rule issue?

Correct: c. Docs: Services vs Alerts. A service with no issue can still be an open RDP. Re-read Discover → attribute → remediate.
Q4

A service shows Externally Inferred CVE-2021-41773, High Confidence, Apache 2.4.49. What is that?

Correct: b. Xpanse cannot see the OS or mitigations and aims to over-match. Re-read Xpanse vs scanner vs CMDB.
Q5

The RDP issue is open. Service row Tags show BU empty. How do you give it an owner?

Correct: d. BU tag is on domains and IP ranges. Bulk CSV max 50 rows; BU must already exist. Re-read Side B.
Q6

Cloud-Dev just denied Internet→3389 on the NSG. When is the exposure actually closed?

Correct: a. Closure evidence is the later scan. NSG save, XSOAR close, and rule disable are not the internet view. Re-read Side C and Traps.

Sources

Related: XSOAR playbook lifecycle · Palo Alto operational failures · All lessons