Can you give us a quick take on what asset metadata is and why it’s important in the context of vulnerability management process automation?

Aaron: Asset metadata ranges from things like who owns the asset, who supports the asset, the different applications that could be deployed on that asset. If that asset is running or it’s been deactivated, you know, moving into a highly hybrid cloud and on-prem environment these days, um, you have a mislinkage of data that really you don’t know if it’s running or not. As we’re moving into more so ephemeral style environments with the introduction of Kubernetes and containerized environments, you have environments that are constantly going up and down, up and down every single day. So, ensuring that you have this metadata there so you can properly allocate vulnerabilities to the respective teams, you can ensure that the correct vulnerabilities are in fact being remediated by the correct people, and you’re not chasing down an asset that is no longer even active and wasting precious valuable time during a P1 issue. So, this is asset metadata that can realistically come from anywhere, we’re talking CMDBs, spreadsheets, and also the scanners that your teams have spent so much time in putting together asset grouping rules in services like CrowdStrike. Tenable, and Qualys. So people have tried in the past, but the issue is you have all this dispersed metadata across all these different environments, and actually keeping those different fields up to date is a challenging task.

Adam: What I heard there is that asset metadata are various characteristics on different types of assets. They might be application type assets or cloud resources or even devices. And when I think of asset metadata, I think of properties, you know, properties on an asset thats just additional information that you can use to have more context about that asset.


Aaron: Yeah. Say Kubernetes, for example. You have a team that deploys the image. You have a team that maintains the instance itself. You have a team that writes the code, right? So it may all boil up to a single EC2 instance that’s vulnerable to said vulnerability, and it may pop up in your VM solution that, hey, this EC2 instance is actually vulnerable to this. But unless you have the asset metadata that shows you who wrote the code, who deployed the image, who built the CS CD pipeline, you won’t know who to actually send that vulnerability to. So, at Nucleus, our goal is to consolidate this and be able to automate based off of vulnerability type, vulnerability source, data source and et cetera, to ensure that those vulnerabilities are getting to the respective people.

Would you please share some ideas on what vulnerability management problems that leveraging asset meta metadata and automation really solve?

Aaron: I’m working with a few customers right now where they have a number of on-prem environments, a number of on-prem instances, and these on-prem instances are just single VMs that are deployed on top of a hypervisor, but the teams that manage the underlying hyper hypervisor versus the teams that manage the VM itself versus the team that manage the network, those VMs that they are actually talking through are all different, right? Utilizing our ServiceNow CMDB connector, what we’ve done is we’ve been pulling relationship data of who of all the different applications and all the different teams that are being involved on this asset and bringing that into Nucleus, and then leveraging findings processing rules inside of Nucleus. We’re able to key on the different types of vulnerabilities and then autonomously assign those vulnerabilities to the respective teams within I TS< because we have this TSM app that’s already built into the store.

So, we’re able to write custom business rules that dynamically assign the correct vulnerabilities to the correct teams, when you again only see one VM in snow based off the CMDB information, but if you go up an additional level and you look at the relationship table, all that relationship metadata’s coming into Nucleus. So that’s one quick way of how we’re doing that. Then even building on top of that is the assignment of those vulnerabilities which is one thing, but also setting the risk of that asset, right? So you have all this metadata that’s coming in where it’s deployed, what it’s touching, this sensitivity of the data, if it’s external or internal that we’re getting from all the different firewalls, all the different CMDB information, even spreadsheet information that people can push into Nucleus. And we’re able to normalize that data inside of Nucleus and then autonomously map that to risk attributes that are on top of the asset. So we have business criticality, data sensitivity, publicly facing, and if that asset is in scope for compliance, so we’re autonomously mapping those metadata fields that we’re getting from all these different sources to risk attributes and Nucleus is setting a risk score that’s highly customizable based off of your own business metrics.

That risk score is then being used to calculate SLA dates. So, take for example, let’s say you have a Raspberry Pi that’s sitting on your desk and it’s a test bench for you, and it has the same exact image that you’re using as a bench, as an image that’s potentially in prod or in staging. That Raspberry Pi is going to have the same exact vulnerabilities that that instance that’s deployed on an EC2 instance, for example, what that same image has, right? But the difference is the criticality of that asset for the Raspberry Pi is nothing. It’s a Pi sitting on your desk versus that EC2 instance that is publicly facing. It’s in production, it’s highly available. So then now you have these two vulnerabilities that are sitting inside of Nucleus. One of them is risk a thousand versus one of them that’s risk a hundred. We’re setting the SLAs based off of the risk value of what’s most critical to you, not just what the severity of that vulnerability is. So that way we’re not cluttering up anyone’s feed, we’re not upsetting anyone. So to me, that’s kind of the most important part of Nucleus is ensuring that we’re getting the information to the right people. We’re not cluttering people’s feeds and we’re not giving them false positives. We’re ensuring that they have the correct information they need to remediate those vulnerabilities in a timely manner.

Adam: At the risk of sounding cliché, we’re helping our customers to surface the signals and the noise so that they’re not distracted by a bunch of irrelevant information and vulnerabilities that really aren’t as critical as they might think.

So now let’s actually take a look of some examples in Nucleus and really look at, in a demo environment, how Nucleus customers are using asset to create fine grain automation.