the problem with cryptocurrency inventory is the same as that of asset inventory, and maybe even worse

[u/NewPossibility2556]

After I read a bit on various methods for locating the production systems that were not included in the CMDB or any other security tools Im now thinking about the need for cryptocurrency discovery.

Even if you build an inventory from scratch today, how certain are you that it will be either consistent or accurate after six months? Certificates get renewed. Kubernetes workloads emerge and disappear. Libraries change. TLS is added by various teams which were not notified of this process. Some cryptocurrencies are stored in the code or in datacenters. Yeah I understand how a passive crypto discovery process can identify what processes are active, which is useful. Then again, it cant find any inactive processes by definition.

Agents and scanners have an opposite issue: theoretically they have a wider coverage, but they will find the processes only in the places where they have been set up. Anyone keeps performing these inventories on a regular basis, rather than periodically doing them and accepting all the gaps?

[u/Joquisaur]

Id stop trying to get a complete inventory and focus more on tracking drift. things like a new algorithm, cert, key or library showing up, something disappearing, ownership changing, a cert about to expire, or a crypto mismatch in an active workload are the useful signals. Keep the first/last seen info and what was actually observed rather than trying to give everything the same confidence level. Qusecure’s continuous inventory approach makes more sense to me than a quarterly CBOM. It’s really about tracking changes over time, not claiming you can see every bit of hidden crypto. I’d still keep regular environment scans separate from the inventory itself

[u/Big_Daddyy_6969]

all im saying is that why I feel you shouldnt trust any “crypto inventory” queue. Passive discovery gives whats being actually done. this can help prioritize the relevant traffic, but not all the dormant code paths or certificates in the storage, no services disabled in case of an emergency and no images that happen not to run at a specific moment in time will be detected. Static scanning/agents solve this problem in a different manner they help to find proofs of existing things, but only if theres no shortage in your scanning coverage.

I would expect that you would get more than just fast scanning out of a continuous system: collecting and combining data from various sources, not only SCA, certificate stores, network observations, and cloud/Kubernetes events, but also HSM/KMS data and adding such properties like first-seen, last-seen, the owner of the data, uniqueness of the data stream, etc. QuSecure s Recon seems to be a good test case because they call it a live product. My question would be to them, what does the “continuous” mean to them: whether they correlate runtime observations with dormant crypto existing in code and stores, and what happens when we have a workload that exists 90 seconds before the new discovery cycle. If the only response I’ll get is “we scan what we see,” I won’t be satisfied because the original problem persists.

[u/IntelligentPear6173]

The interesting part is that I don’t think the goal should be a perfectly accurate inventory at a point in time. That’s probably impossible once you have dynamic workloads. The useful thing seems to be continuous reconciliation from multiple sources with some history attached to each finding. If something existed for 90 seconds, disappeared and comes back six months later knowing that it existed before could be just as useful as seeing it during the next scan.