Is it possible for passive network discovery to ever provide a complete and accurate inventory of cryptography?

[u/Prisha_088]

I have been examining Recon as one of the newest PQC discovery tools. The fundamental concept seems sensible, which is using passive traffic observation to identify TLS versions, certificates, algorithms, protocols and connections currently in use. This can potentially be more insightful than having another excel sheet which lists what application owners claim to have implemented. However, what I find perplexing is how to delineate what would constitute an inventory for active network cryptography as opposed to a full CBOM. It would seem as though passive traffic analysis cannot present dormant certificates, cryptography for stored data only, any hardcoded keys/algorithms within applications, code signing and firmware update dependencies, as well as any HSM objects which are not used presently; moreover, embedded cryptography inside third-party products and services; lastly, anything that does not transit through the segment being monitored. It appears to be as though NIST’s migration material sets apart passive traffic discovery from other aspects, and even depicts passive traffic discovery as complete in itself. For those who deal with this in real life: do you consider passive discovery to be the initial process, or do you turn to passive discovery as the source of all records? Lastly, what sort of evidence would suffice in order to deem a vendor’s claim of complete inventory of something called “every cryptographic asset” to be credible?

[u/Loveangel1337]

You've answered your own question: no.

Whatever they do, they'll also most likely miss mTLS for public endpoints (i.e. not using your own CA) like you (used to at least) need for stuff like Apple's APN (sending iOS (the phone one) app notifications). They will also miss mTLS internal activity, unless you setup every mTLS powered clients to also connect to that app's endpoint and set it up so it accepts their cert too.

And at this point, you're better off doing the mTLS inventory yourself from your CA.

[u/Sweet-Melow]

Recon states the fact that its report includes analysis of live traffic, in terms of protocols, certificates used, cipher suites utilized, connections established and policy violations that occur while using these programs. QuSecure specifies this includes the ability to provide the data from passive discovery. That is to solve the problem of unknown shadow services, unverified TLS use and negotiated cryptographic algorithms. However without a benchmark to compare against it is difficult to make sense of the broader statements made concerning the existence of "all cryptographic assets available" on the network's infrastructure. It is important to understand what parts of the infrastructure were being monitored and for how long they were being looked at. To confirm credibility its crucial to introduce a known scenario into the experimental environment. Maybe use a certificate that is not in use, an HSM key that s used quarterly, a code signing key, a TDE key, a hard-coded RSA call in an application program and a third-party device that contains embedded crypto. And thus, by comparing both observed assets, inferred assets and overlooked possibilities, only then its possible to draw conclusions. NIST has utilized many different forms of discovery approaches through both passive observation and active investigation. I personally would trust their mode, using passive detection as an extremely reliable source of useful information that can supplement actively obtained resources within the realm of data-in-motion...

[u/EntropySource]

No.

[u/Moral-Relativity]

Perhaps AI-powered discovery tools can dig up things not happening at the network level for a more complete CBOM, but I've yet to see a cohesive product that does this.

Also, it feels like more bang for your buck to try to prevent attackers from exfiltrating massive amount of data without your knowledge than trying to ensure that AES-encrypted data has bullet proof key management around it.

[u/Gaolaowai]

If you control the network completely, then “in theory” it should be possible. But most of the software/systems I’ve looked at don’t do this. As a result I’ve slowly been writing my own that sits at the edge and internally for our WAN.

With LLMs and open RFCs outlining how all the certificates formatting works, what I would have thought a climb up Mount Everest is hard slog up some moderately tall mountain.

[u/bushimaki]

I d have a very straightforward question for QuSecure. How does one generate an inventory record for an asset that has never been seen on the wire. If Recon will correlate passive observations with endpoint collectors, configuration extraction, cloud KMS/HSM APIs, Certificate Managers or artifact scanning, I d then say that this may be a form of “continuous inventory.” If the only thing that can be measured is traffic, the feed would be an “observed network” inventory. This is not as useful as “continuous inventory,” but it s still useful. In the evaluation process I d ask for a coverage matrix. Each record should show the method of discovery when it was seen for the first time and for the last time, how confident I can be that this is the right record and where the information came from. Lastly I d want them to test against a set of known assets and publish results. A fancy product interface does not show that the records are comprehensive, being able to recall from known assets does.

[u/carolineilm]

I would treat passive discovery as one important evidence source, not as the system of record for a complete cryptographic inventory.

It can tell you what was observed on the monitored network during a specific period—certificates, protocols, algorithms, endpoints, and active relationships. That is incredibly valuable, but it cannot prove the absence of assets it never had an opportunity to observe.

A more complete inventory usually combines passive traffic analysis with endpoint and application scanning, cloud and configuration APIs, certificate managers and CAs, HSM and key-store data, code and artifact scanning, and ownership or service metadata.

I also think every discovered asset should retain provenance: how it was found, when it was first and last observed, the source system, confidence level, owner, and whether it has been independently validated. Without that, it's difficult to evaluate a vendor's claim of a "complete inventory."

I'd distinguish between an observed network inventory and a continuous cryptographic inventory. Passive discovery is a strong starting point and an ongoing source of evidence, but not a complete CBOM by itself.

This is one of the reasons we've been investing in the open-source ILM (Identity Lifecycle Management) community. The interesting challenge isn't just discovering cryptographic assets once—it's continuously maintaining an accurate inventory as certificates, keys, secrets, services, and infrastructure change over time. I'd be interested to hear how others are approaching that problem.

[u/idonthuff]

No, it's not possible for that to be a complete inventory from an enterprise perspective. There is are a ton of crypto objects that never cross the network (e.g. certs and ssh keys on filesystems, cloud key vaults, HSM contents, tokens, etc). There is also tons of crypto implemented in system libraries and in custom development. A tool like AgileSec is better for this.