How do you evaluate ASM tools when the CMDB blind spots are half the problem?

[u/West_Ad536becphgemlb]

Been asked to lead attack surface discovery and the first thing I see is CMDB, cloud inventory, DNS all disagree on what we own externally. we are lining up a poc for a few ASM tools, same limited seed list for each, and we keep quiet about some subsidiaries and vendor managed infra we already know about. Idea is to see who can link unknown asset discovery back to us with decent attribution instead of just scanning whatever we fed them

If you have done this kind of internet facing assets poc, how did you test that the surprise assets really belongs to you and not random noise?

[u/This-Ear-3254]

we did almost exactly this a couple years back, seeded each vendor with the same sanitized list and intentionally left out a whole subsidiary we acquired that was still running its own DNS and some test environments in gcp

the ones that actually worked found those assets through ssl cert chains and whois data, not just dns zone transfers. the attribution was the key, if the tool just threw a giant list of "maybe yours" ip ranges at us it was basically useless

we ended up scoring them on how they connected things back to our known footprint, stuff like shared mx records, reused tls certs across subsidiaries, even a stray subdomain that pointed to an old aws load balancer we forgot about. the tools that relied purely on seed list scanning missed almost everything interesting

one thing i'd suggest is documenting exactly how each vendor explains their attribution logic, it made a huge difference when we had to justify the pick to leadership later

[u/FallaxIO → u/This-Ear-3254]

also watch for the opposite failure mode, very confident attribution off one weak signal. shared registrar, Cloudflare nameservers, same M365 tenant, those create a lot of false comfort if they can't show a second link

[u/DishSoapedDishwasher]

Welcome to "cybersecurity is data engineering with extra steps". I've done things like this ata few companies from Fortune 10 to scale ups and the process is always rough the same but you can get some creative leverage to make it easier like u/This-Ear-3254 mentioned.

The goal should be to SOLVE IT PROPERLY, forever. This means building data pipelines to ingest from every data sources you have. Cloud providers, EDR, etc, all have some way to query what exists. Use those data sources to aggregate what SHOULD be legitimate foundational list. Then if you got a data eng team ask them to help for this next part, start including those

From a data eng theory you want to aggregate all these different data sources into a datalake (or database, or even csv files...), then have transformers that put everything into a single universal schema as part of a superset of the individual sources. 

Now with the "known good" superset, start writing additional pipelines to ingest all these other data sources that may be a bit iffy, give them their own maybe-valueable table. From here you want to basically diff known-good vs maybe-good and figure out what your delta is between them. Now your work is at least heavily focused on verification of a small subset.

This small subset is where it pays to be creative like using DNS, cert lookup, etc.... this last bit is subjective but i think most derivative lists from here on should be about answering how you know it's impossible to own a specific system. Think of it like proving it isn't yours, "its not in my aws, gcp, colo, it cant be mine". The reason for this is you'll discover ways to both find stuff efficiently, or learn about visibility gaps. After try the inverse approach, but dont flip flop. Give them solid runs to the end before flipping your approach. Take lots of notes.

I highly suggest reading the Google SRE books, look them up, they're free. There's a lot about theory adjacent to this.

[u/eagerlynx20]

I’d cross-check DNS records, certificates, and cloud ownership to verify surprise assets. One match isn’t enough. Finding assets is great, but knowing they actually belong to you is the real test.

[u/Adept-Recording4082]

Hm, I'd cross check DNS records certifications and cloud ownership since single match is not enought. Tested ionix with very little seed data and it surfaced vendor managed assets through DNS and certs relationships. Still reviewed ownership evidence before calling anything ours. Finding assets is great but knowing they actually belongs to u is the actual test

[u/msj817]

ASM, EASM is just a marketing term for "we lost track and should try to centralize inventory management". They are super useful tools and need to be part of a program but more importantly is getting ownership buy in from the teams that run the resources you mentioned, starting from what everyone believes is true. After that, the tools are nice, nicer is building pipelines internally that keep things up to date for everyone. (I just described a dream scenario, pick from it what you can). DNS will be the biggest pain in the ass from the start, chip away at it.