← Risky Bulletin
Loading summary
Transcript26 lines
- [00:00]
A
Foreign. This is Kathleen Campano and this is a Risky Business News sponsor interview with Aaron Atarzadech, Enterprise Security engineer at Nucleus Security. Welcome, Aaron.
- [00:15]
B
Thank you so much for having me.
- [00:16]
A
Aaron. Vulnerability management companies have always had an image problem in the eyes of customers. You go to a security conference or a trade show and people would often dismiss your craft on the premise that you work with a fixed amount of data points from a cve. Many times you hear people say that they can easily put together a script, scrape a CVE database, and then use that to pass their stuff. However, when we set up this interview, you sent me an email where you wrote that customers have way more data at their disposal than they think they have. Where does this discrepancy come from? What are you exactly referring to when you say there's more data in vulnerability management processes than people think?
- [00:56]
B
Yeah, great question. So normally most vulnerability management teams, they're looking at just their scanners that scan the infrastructure. Right. We often forget that there's often endpoint agents that are being deployed on those systems. There is the infrastructure team that's managing the vms or the EKS clusters, the GKE clusters that is being deployed. So these are all different data sources that VM solutions can plug into to pull data that the scanner isn't pulling, as an example.
- [01:26]
A
So from what I understand, there's a little bit of asset correlation and asset management, which is just as important to modern day vulnerability management as the good old vulnerability scanners.
- [01:37]
B
Yeah.
- [01:37]
A
When do you think this became the norm? With the first APT attacks, with the rise of ransomware, with the move to the cloud, when did people go from, I just can't apply every little patch. Let me start splitting assets in tiers and categories.
- [01:52]
B
Yeah, I think this came about with the mass adoption of cloud environments. I think Covid played a big role into this, where people could no longer go in person, so they're no longer managing on prem assets. So a lot of people started deploying cloud environments and started the mass migration to the cloud. And you're no longer just supporting one vm, you're no longer just supporting one host, you are now supporting the eight assets that are surrounding that host, such as a vpc, a security group, the IAM roles tied to it, the volume that's tied to it. Right. So we go from just managing one source with maybe a load balancer in front of it, to now eight separate assets that are all surrounding a single vm. So it's an explosion of data now.
- [02:35]
A
So as you say, it's an explosion of data as a vulnerability management platform. How do you collect all this metadata? Where do you collect it from? And then how do you deploy it to customers?
- [02:46]
B
We are big proponents of plugging into everything. So we don't just look at the VM scanners themselves. We, we're looking at the underlying cloud environments like AWS and GCP and Azure OCI tying into the cloud environments itself, reaching out to it, asking if they have any EDR solutions that are being deployed on those hosts, reaching out to the infrastructure team that maybe has a CMDB that's also doing discovery scans within the environment, ingesting data from them. Also even the application team, they may have spreadsheets of who owns what application that's being deployed in what AWS account. Right. It's all different bits of metadata that's completely across the entire organization and no one has a good way of aggregating that data until now.
- [03:34]
A
So there is some sort of customer input in the rollout of your platform. Right. Like you don't use any type of automated system that just automatically classifies and categorizes assets based on their importance. You also need the customer to chip in, right?
- [03:49]
B
Not necessarily. So there is, that's the beauty of correlation is every different data source provides different metadata that one doesn't have. For example, you may pull from AWS production environment versus a staging environment or security group controls around what security group is publicly facing versus which one is not publicly facing. So we're pulling from the different data sources, the underlying metadata that can fill in the gaps that different data sources that are giving us data cannot fill in those gaps.
- [04:21]
A
We think the way cloud infrastructure is usually set up encourages this simpler way of categorizing data. Because of the role based systems usually.
- [04:31]
B
Having cloud platforms, I think everyone has a unique way of deploying their architecture. They have a unique way of deploying applications. No one customer is the same. It's. It's giving them a platform that is completely flexible to how they deploy their application, how they interact with the cloud, be able to morph and work with their current deployment.
- [04:53]
A
Stack networks inside. Large companies also have this tendency to change all the time in both size and content. People add and take those systems, especially in the cloud. How do you deal with this? What would be the typical time between when you detect a new system and add it to your dashboard and like do you prompt clients about it to ask them what this is, where this belongs, how important this is?
- [05:21]
B
Yeah. So ever changing data, right. It's a constant problem that I think everyone deals with on a daily basis. You know, whether security group changes, whether a cluster is continuously redeployed. For us, we do real time syncing with the cloud. So it's a matter of setting up mapping rules or setting up automation rules within Nucleus that are continuously being triggered every single time a new event or new asset is brought into Nucleus to ensure that we don't display stale data. Right? If you start assigning vulnerabilities out to engineers for remediation within a cluster and you have 10,000 containers, and today you have 10,000 containers, but tomorrow it's dead and you have a whole brand new cluster, that's just useless work. So it's about keeping real time data within Nucleus, within any platform really, and ensuring that it's the most up to date data.
- [06:14]
A
This trend of increased attacks, targeting edge devices, using them for initial access instead of phishing, and how this has triggered for many companies, more increased focus on securing edge devices and systems that can be used for initial access. I was wondering if this has triggered any kind of response from customers like, okay, we know these are under attack. Do we have any ways to keep them under a closer grip than the rest of our assets? Like in a class of their own, like a CISAK section or something?
- [06:48]
B
This is a great question. So we look at things like end of life, we look at vulnerabilities that are exploitable on end of life assets that can't be patched, right? And when we think of risk in Nucleus and just even outside of Nucleus, right, It's not just the vulnerability context, it's the asset context, right? So I think of this as an upside down tree where the left branch of this tree is the context of the asset. So imagine you have the same vulnerability across two different assets. One is EOL and one is a fully supported asset. The one that's EOL is out of compliant. So the risk of this asset being exploited is higher even though the they have the same vulnerability on them. So when you start doing things like assigning due dates and prioritizing and boiling things up to the top, that vulnerability that is on an EOL asset will dynamically be adjusted and bumped up to the very top of the list versus something that is patchable that you can update the operating system or you can patch the host. This is a very common use case that we see on a daily basis. And by just looking at the vulnerability scanner and surfacing the vulnerabilities, you can't get that contextual data that the low level data of like is this host, you know, if it's just like an external scan, right? If you're just doing an external scan and you don't have like the build information from like a Windows build, right? You may not know it may be Windows 10, but what version of Windows 10? What build version of Windows 10, right? And being able to cross correlate from like let's say CrowdStrike that's embedded onto the host itself and from the external scan, you now have the build information from CrowdStrike correlated to the vulnerability that maybe NESSUS is giving you or what the Daskan is giving you. That's where the real power of correlation comes in. So. Very much so, yes.
- [08:28]
A
Are there other kind of examples where correlation usually plays a big role in prioritizing patching, like besides edge networking devices, like let's say internal static systems inside a ad network, something like that?
- [08:45]
B
That's a very common one. We see a lot of customers use DLP solutions like Rubrik, where Rubrik is scanning for things like credit card information, social securities and stuff like that. And being able to correlate not just your EDR solution, but DLP solution just like Rubrik and saying, hey, this host that has an exploitable vulnerability, has sensitive data on it, prioritize this higher than a host that doesn't have sensitive data on it, or something that is in staging, right? Like it's not just the EDR agents, it's not just the cmdbs. Think outside of the box. Other teams within the organization are scanning those same hosts and they have additional data that you can leverage to prioritize findings.
- [09:30]
A
So how do you help larger teams prioritize assets in a coherent way? Is there any specific trick to avoid overlaps or assets getting lost?
- [09:39]
B
Yeah, like asset linking is a big one. We see a lot of the times where customers want to be able to pinpoint and runtime. Hey, I may have a vulnerability that's being scaled out across an ASG, right? Thousands of VMs. And I'm not remediating at the AMI, I'm not remediating at the image I'm remediating in my repo. How do I correlate the runtime environment back to the REST environment? How do I correlate it back to which repository actually built this image that's being deployed in this cluster and through the power of plugging into the multiple different systems, whether it be plugging into your shift left scanner within your CI CD pipeline, that's giving you the image and the SHA of that image that's being Then in turn deployed through cloudformation script in aws, you're able to correlate from runtime all the way back down to rest to be able to pinpoint specifically where in fact that vulnerability surfaced. From now, these are just small examples of a scanner won't give you all that metadata. You have to think outside of the box of how to pull the metadata to correlate both vulnerabilities for prioritization and contextualization.
- [10:49]
A
Where is asset linking usually useful in AppSec environments. Right. Usually where you have CI CD pipelines. Right.
- [10:56]
B
AppSec is a popular one. A lot of the times think of a development cycle right after you build an image and you want to move that image to a staging environment to do testing on it. You may go through multiple environments, whether it be staging QA and ultimately or QA staging and then ultimately moving it to production. Right. A lot of the times customers leverage things like the cloud accounts to separate the different environments and being able to map the Cloud account IDs to risk pillars in a platform to say these cloud accounts are the highest priority cloud accounts versus, you know, staging, maybe second priority and then lowest priority is qa because that's within my zero trust environment. You know, no one can access those hosts unless you're on zero trust. Right. So the correlation of sure, I'm scanning externally with a vulnerability scanner, but then correlating that to potentially AWS or GCP to give you the cloud account information to then in turn prioritize the vulnerabilities that are surfacing from the external scanner higher or lower based off of where it's actually being detected on. That's just a clear example of asset correlation that is very useful for a lot of our customers.
- [12:12]
A
Okay, I think that's a great way to end it. Aaron, thank you very much for your time today.
- [12:16]
B
Of course, really appreciate it. Thank you for having me.