Adopting Zero Trust
Adopting Zero Trust
Applying Vulnerability Management to Zero Trust: Insights from Fortra’s Tyler Reguly
0:00
Current time: 0:00 / Total time: -45:43
-45:43

Applying Vulnerability Management to Zero Trust: Insights from Fortra’s Tyler Reguly

Season 3, Episode 11: Vulnerability management is critical to any Zero Trust strategy, but you probably already know that. Fortra’s Tyler Reguly breaks down severity vs. risk.

Catch this episode on YouTubeAppleSpotify, or AmazonYou can read the show notes here.

Every organization relies on some form of technology to run, and each tool you add increases the risk of vulnerabilities causing problems. If you don’t stay on top of patching, you increase the odds of a bad actor finding their way more easily within your network.

This week, we chat with Tyler Reguly, a senior manager of security research at Fortra, who shares insights from his 18 years in vulnerability management. Tyler discusses the importance of staying on top of patching to maintain a Zero Trust strategy, the differences between vulnerability and patch management, and emphasizes that the Common Vulnerability Scoring System (CVSS) measures severity, not risk.

We also briefly nerd out about the significance of groups like the Canadian Cyber Threat Exchange (CCTX) for knowledge sharing and collaboration in cybersecurity. And then, we wrap things up by exploring the efficacy of existing security policies and benchmarks, such as CIS and DISA STIGs, and the role of vendor relationships in maintaining effective security practices.

Key Takeaways

  • The Common Vulnerability Scoring System (CVSS) measures severity, not risk; a broader risk assessment methodology is necessary.

  • Prioritizing public-facing systems and user base risks is essential due to common exploitation methods like phishing.

  • Effective patch management requires vigilant testing to avoid false positives and unnoticed vulnerabilities.

  • Collective defense groups like the Canadian Cyber Threat Exchange (CCTX) enhance security through knowledge sharing and collaboration.

  • Security Configuration Management (SCM) and standards like CIS benchmarks are beneficial for enhancing security beyond just patching.

  • Building a robust Zero Trust program involves leveraging community insights, prioritizing critical patches, and continuously validating security measures.

Editor’s Note

Heading to Black Hat? Neal and I will be there! Please reach out if you are interested in chatting. We’ll likely record some mini-episodes. We’re also booking our standard episodes out through the rest of the year, so if you have fresh research, hot takes, or implementation stories, we’d love to get them in front of our audience.

Transparency note: Elliot now works at MSFT and will not discuss anything that takes place there or about the company. You can check out the fancy threat intel podcast for that.

The Importance of Patching in Zero Trust

To set the stage, we kick things off by addressing a fundamental question: how critical is it to stay on top of patching in a Zero Trust strategy? Tyler offered his perspective, underscoring the surprising notion in some circles that Zero Trust could reduce the urgency of patching. He emphasized that, in his experience, patching remains a crucial element as you have to operate under the assumption that a breach is inevitable. He elaborated on the necessity of knowing what's out there, prioritizing risk, and knowing how to deal with vulnerabilities.

Community Involvement: CCTX and Vulnerability Information Sharing

Tyler shared one of his enriching experiences with the Canadian Cyber Threat Exchange (CCTX). He highlighted the enthusiasm and commitment within the community towards making vulnerability management programs work. Tyler emphasized the advantage of seeing cybersecurity as a team sport through such communities where knowledge sharing and active participation significantly enhance the collective security posture.

Zero Trust Policy and Vulnerability Prioritization

Neal then led us into a brief rabbit hole, diving deeper into the nuances between traditional vulnerability management and Zero Trust policies. Tyler explained the varying degrees of advancement within Zero Trust implementations, noting that the maturity level significantly affects the overall benefit. A key takeaway was the emphasis on prioritizing public-facing systems and user base risks due to the common tendency for humans to fall for phishing attempts or other exploitation methods.

Security Configuration Management and Standards

The conversation then shifted to security configuration management (SCM) and standards like CIS (Center for Internet Security) benchmarks. Tyler highlighted the importance of SCM, noting that patching, while essential, is just one layer of the security stack. Implementing robust configuration policies can make systems more secure even with vulnerabilities, further complementing Zero Trust principles.

The Role of CVSS in Risk Prioritization

Tyler touched upon a core aspect: the Common Vulnerability Scoring System (CVSS) and its role in measuring vulnerability severity, not risk. He clarified common misconceptions about CVSS, advocating for its use as a severity indicator while emphasizing the necessity of a broader risk assessment methodology to truly gauge the impact on an organization's specific environment.

Vendor Trust and Vulnerability Management

Understanding the credibility and context of information from vendors is paramount. Tyler shared anecdotes illustrating both the pitfalls and benefits of relying on vendor-provided data. He stressed the importance of validating vendor claims, understanding the nuances of potential media hype, and trusting reputable vendors who provide clear, detailed, and immediate action plans for critical vulnerabilities.

False Positives and Patch Management

Toward the end, Tyler discussed the ongoing challenge of false positives in vulnerability detection tools and the critical need for effective patch management. He illustrated real-world scenarios where lapses in proper patching resulted in unnoticed vulnerabilities, reinforcing the message that patch management requires vigilant testing and verification beyond just automated updates.

Our conversation wrapped up with a light-hearted but insightful dialogue on the intersections of vendor management, supply chain risk, and the personal nuances each brings to contributing to community-driven security initiatives. Tyler's contributions and insights undoubtedly highlighted the importance of proactive vulnerability management in shaping strong Zero Trust environments.

In essence, this episode underlined that building a robust Zero Trust framework isn't just about implementing technology but also leveraging community insights, prioritizing critical patches, and continuously validating security measures. Stay tuned for more deep dives with experts like Tyler who bring invaluable perspectives to the evolving world of Zero Trust.


Thank you for joining AZT, an independent series. For more detailed insights from our episodes, visit adoptingzerotrust.com and subscribe to our newsletter.


Show Transcript

This transcript was automatically created and is undoubtedly filled with typos. As usual, we blame the machines for any errors.

Elliot Volkman: Hello everyone. And welcome back to adoption Zero Trust or AZT. My name is Elliot Volkman, your producer alongside Neal Dennis, our host, and Tyler is going to be here talking about a subject that we have somehow neglected to cover in this equation, which is.

As basic as it gets when it comes to a Zero Trust strategy to enjoy that. I don't mess up your background and important brand names and whatnot.

Tyler, maybe you can give us a little bit of a background on yourself and how you got into your shoes today.

Tyler Reguly: sure. So I'm a senior manager of security research at Fortra. I've been in the vulnerability management space now for 18 years. And through a series of acquisitions, I still work with the same product I started working with 18 years ago, which is An odd thing, I think, to encounter in that industry.

People usually move from time to time. But we were in circle, we were TripWire, TripWire was acquired, TripWire was acquired again. Now we're Fortra my role has since expanded that I have I now look at vulnerability management across multiple products. I look at MDR and XDR a bit now, research.

My love has always been vulnerabilities, vulnerability research. I, I started out, as a teenager in the mid 90s playing with this stuff and sitting there on the slackware box compiling old C exploits just to see what they would do. And I've just been in love with it ever since.

And it hasn't changed since then. So thanks for having me. I'm excited to talk about this.

Elliot Volkman: yeah, absolutely. Likewise. And I can already see Neal grinning. You've definitely said some right terms there to perk his ears up.

But you also said the key word, which is what we're going to be talking about today as it relates to modern cybersecurity strategies. And of course, your trust, which is trust.

Vulnerability is patching the very most basic thing that somehow, again, we have neglected to talk about. So I love just to tee this off with a nice little softball. Maybe you can give us a little bit of perspective of in this whole world of Zero Trust through the lens of, we have to go under the notion that you're probably breached or you have to run under the notion that you are already breached.

How important and how critical is it to stay on top of patching?

Tyler Reguly: It's interesting because I, again, I, vulnerability management, I don't talk a lot about Zero Trust. So I did a whole lot of reading to make sure I didn't sound like a fool. And I still probably will. But that's okay. And I was actually surprised to see a number of, of articles out there that said Zero Trust means that you Don't have to focus on patching with as much priority as you otherwise might have to.

That surprised me. Now again, I, I live and breathe the vulnerability management space. So it's something that is near and dear to my heart and I consider it critical. But in my mind, Yes. Are you breached? When will you be breached? It's not a matter of, if you'll be breached, it's a matter of when.

And one of the easiest ways to stay on top of that is to stay on top of your patching. Know what's out there, know how to prioritize your risk and, and know how to deal with everything that's coming at you.

I think the biggest thing and one of the coolest experiences I've had this year, if I can go on a bit of a tangent Is I'm involved with the Canadian Cyber Threat Exchange, CCTX, and one of the things that I've been doing there is actually running a vulnerability community of interest for Canadian companies every, two weeks or so we meet and talk and one of the things that I've found is that.

A lot of people really want to make their vulnerability management programs work. A lot of people are keen to see it work. They just don't know how to get to that point. And I think that I've rambled a lot. But I, I think that knowing how to properly, properly prioritize things is really key to Not just applying those patches and understanding them, but securing your overall environment because you have limited resources and patching isn't the only thing you have to do.

So knowing where to put your resources and how to use them and how to properly prioritize the overall security of your enterprise is probably the most important thing for people.

Elliot Volkman: That is a fantastic question, and usually I would ask a follow up, but you also hit another term, which is basically the collective defense. So for the U. S., we have ISACs and, for anyone that's listened probably knows that Neal has a strong love affair or interest with Isaac, so I'm gonna actually just hand that off right over to you, Neal.

Maybe you can go there because I don't want to hold you back and I feel like I can just see you're ready to go. Transcripts

Neal Dennis: Nah, I just find it's always fun when day to day life syncs up with podcast life in one way or another. And Tyler, you're not rambling. I'm going to teach you how rambling works here in a few seconds. That being said, CCTX is someone I work with as well. From a product perspective. So I, my day life, my day job, they use one of our products to impact that membership from a portal and, and collaboration perspective.

So we'll, we'll, we'll talk about that maybe offline as far as what that is a little bit more. So that's pretty cool.

Now, one thing I want to maybe highlight real fast before I ask a couple of questions, I want to make sure people understand That Zero Trust Policy and Procedure isn't obviously saying don't patch or de escalate or de prioritize or don't make it an important thing.

It's, it's more of a, let's look at. What types of vulnerabilities are typically taken advantage of, especially things like remote execution stuff related type things and what happens once that that is exploited? How does how does the pivot occur? And why does the pivot occur? I can get into a server with some exploit, right?

With some R. R. C. E. But. Once I'm there, if you have the right Zero Trust policies, then you should really still just be there, in theory, minus additional exploitation paths that aren't patched or available. I, I think for the listeners, just understanding that criticality and understanding your, your prioritization still needs to happen at a very base level, but there is some leniency towards what happens once the exploit is It's taking advantage of, for what that threat actor has as a next step, if you've taken due process around a Zero Trust implementation and any time on a server is still bad time on a server.

If it's from a threat actor, no matter what you've done to block down the rest of it. So then. That in mind thinking about, the, the, the chain of impact and stuff of that. We, we see old talks around security and, and security in layers, defense and death make it like an onion, prioritize your things based off of, either the lowest common denominator or the biggest impact, whatever, blah, blah, blah, words, words, words.

So from your perspective, thinking about what you've already going. What would be some of the key advice to help maybe refocus prioritization or what would you think would be impactful to still take into account to prioritize these data points? Should we focus on exclusively say, Hey, Zero Trust behind the firewall is great behind the gateway and DMZ is great.

Let's just go ahead and manage all the legitimate blatantly Internet spacing stuff because Zero Trust will take care of it all. Or should we still fully understand that? An exploits an exploit and it can still get around the Zero Trust framework.

Tyler Reguly: Yeah, I think so. I'm gonna step back and say one of the things I've seen is that there are degrees of in everything, there are degrees in vulnerability management, there are degrees in Zero Trust. And I think that it depends on how far along you are in your implementation path. in both of these things.

If you're all the way there and you have a full Zero Trust network in place, yeah, it's going to help you a lot. But if you're in your infancy and just starting to implement Zero Trust in your environment, it's not going to necessarily help you as much as somebody who's made it to the end and cross the finish line.

If you can ever really cross the finish line in anything with tech, but when it comes to, what do you prioritize and where do you look? I think there's two primary things that tend to cross my mind. One is that publicly accessible stuff that you just have to deal with it. If we look at what's been going on in the last week, we saw the, the Palo Alto vulnerability, the global protect vulnerability.

Cisco yesterday just dropped the arcane door, I think is what they called it campaign. It's got three new CVS that are impacting ASA's and Ftd firepower, threat defense, and I think that those are critical things that you have to look at because those are systems that are sitting there with public IP addresses that anyone's going to be able to poke.

The other thing, though, is your user base. And let's be honest, people are going to click links the number of times in the, forget the enterprise. The number of times that I've had family members and friends call me and say, oh, I got an email that said I had to pay a, a, a fee on a UPS shipment, and I clicked it and gave them my credit card, but I don't think it was real or.

I called I called tech support because I had a pop up when I visited a website and it said I had to call them and they wanted to remote into my computer to fix stuff or, people click these things all the time and the same people that are, my family and friends clicking these are people who are employees.

Enterprises and organizations. So you really need to think about that end user desktop, how it's sitting, what you can do with it. And what does that user have either on the desktop or what do they have access to? And and start to assign asset values, right? Is, is this a critical server? Does this server have financial data on it?

Because quite honestly, if you've got a server that's processing credit cards versus a server that's serving your static web page. I would say one is a little more important than the other at the end of the day. So I think taking asset values into account is really important. And I think thinking about those two spaces is really the, the critical things that you want to think of.

It

Neal Dennis: There's the mute button. So I think from a, from a vulnerability management perspective, I think this is a fun exercise where if you're doing those types of assessments, I think those types of assessments let me back step. If your vulnerability management team has done their job or is doing their job and they understand the infrastructure, at least at some significance.

To understand the prioritization impact. I think that's also potentially your list for prioritizing what you should start doing when you're building out your Zero Trust policy and, and what infrastructure you should obviously look to start wrapping that around as you build your layers into that. So I don't know if that's an agree or disagree moment, but I would like to imagine that the things you prioritize from an updates perspective are the ones you should obviously prioritize from securing in as to a new modality.

Tyler Reguly: Makes perfect sense to me. Yeah.

Neal Dennis: Yeah. What I heard is I'm going to go harass you. You're going to have the prioritization because you're my vulnerability management guy on my team. And you're going to help me build my Zero Trust policy from that prioritization procedures that you've built already on my behalf. And I'm going to check the box with one less thing I have to do.

Tyler Reguly: Nope. That makes sense to me.

Then all we got to do is sit down and figure out how we're going to fit in whatever policying or benchmarking mechanism we're going to use, which I don't want to derail the conversation, but I just want to point out that way too many vulnerability management programs don't take security configuration management into account.

They either treat it as two separate things, like often SCM still lives with IT people, I find, and not always living with security and CIS benchmarks or DISA STIGs or whatever policy you want. The number of policies, especially once you get into various governments implementing their own policy, there's so many out there that you might have to adhere to understanding which ones you, because of regulatory reasons, need to apply to or comply with, and which ones you should from a basic security hygiene standpoint, once you apply those, the thing that I've always found really cool is that, Yes, vulnerabilities are a concern, but there are things that prevent the risk of exploitation from either occurring or minimize the risk of exploitation happening.

Zero Trust is obviously one of those. You can try and prevent pivoting around the network, hopefully restrict them down to a single system, but If you go a step further and you've got a properly applied configuration on the box, the box is securely locked down with a, again, I'm going to go with CIS benchmarks because I think they're the most well known.

So I'll, every time I say CIS, just know I'm, I'm just using a generic term. You lock them all down and use the full CIS policies and you implement level one, level two Of those policies, you end up with a relatively secure box and a lot of other ways as well. You can have your Zero Trust network.

Now you've got your hardened device. And now patching your vulnerabilities is just one more layer that you're adding on top of that. And so I think it's really about putting all those together. And to your point about defense in depth and layering the onion it's I'll go with a different one.

I hope I'm still here. It's a trying to reconnect. But I'll go with a, a different one and say that it's almost like you're building a lasagna. Again, I'm a big guy. I love my food. But, you've got to, you get that base down first. And then it's just about stacking those layers on top of each other to, to get to a point where you secure yourself as much as possible.

Elliot Volkman: is

Neal Dennis: with a good lasagna. My family's part Italian on my mama's side. So that's a great analogy for my stomach. I know I don't look it, but.

Elliot Volkman: University

Neal Dennis: yeah, there's a lot of lasagna packed away behind these, these these layers. No, so you're, you're talking about some of the benchmark items here and you come back to CIS and, just cause.

Familiarity or possibility. Like you mentioned, you think that's a good standard. Are there out of the host of standards and process flows, CIS being one of them, are there other recommendations or other things that people should look into if they're just really getting started from that consideration?

Echelons and things that you would suggest to go poke and prod so they can get a better understanding of where they really should be from those benchmark standards? Yeah,

Tyler Reguly: So I think I like CIS and I like talking about CIS because. It's almost like entry level, like it's table stakes. You want to get in there and, and the fact that they break it into, so if you're not familiar with the benchmarks, they break it into various levels. And here's the things that everyone should do.

Here's the things that you should do if you're a bigger organization with a security team. And here's the things that you should do if you're like a nation state target type levels. And so that first one, that table stakes level one stuff. is simple. It should not take a lot of effort on the part of an organization to implement it.

So that's why I like talking about it, because it really is table stakes. Now, when you want to move forward from there I think it's important to think about who you are as a business. And that's where I think the regulatory policies start to come into play. If you're doing business with the government, dis a stakes are going to be very important to you.

And you better know that. and what they contain. If you are payment card stuff, PCI obviously is the standard you want to pay attention to. So I think that NERC SIP for energy, that's a big one, obviously energy companies. I think it was last week, the FBI issued another warning about potential nation state attacks coming in against infrastructure.

Those are all big ones. But I think really. When we're talking about the security configuration management space anyways, I do think that CIS is just where you start and then just build from there based on the, the vertical that you find your organization in.

Neal Dennis: that makes sense. So shifting slightly. Back into collective defense and CCTX a little bit. So you talk about your participation there in that community and your involvement within that particular group. So thinking once again about a little bit about standards and impact and what that means.

Are you finding that in this particular community, and this isn't to call out the efficacy or quality, but just in general in a community perspective, Are you finding that these types of discussions are. Are taking place in a, in a good light and, and having good interactions. Are you finding that there's still people coming along and yeah, maybe I'll talk with you about it or, or not, or, is there good involvement from the community at large when you offer up these chats?

Tyler Reguly: yeah, I, So I, I've been we've been a member of CCTX for a while. I didn't originally attend the meetings and I started attending them last year sometime. And I think the first thing that stood out to me and I hope it's the same for all the other ISACs that exist, that they're all like this because it's phenomenal, is one first of all, and foremost, and I just want to give a shout out to the people that run CCTX, the commitment and care that they put into it and the number of new programs and features that they start up to try and get the community collaborating is just phenomenal.

For example, giving me the space to run. A vulnerability community of interest and bring together like minded individuals from across Canada to talk about it. And the participation in those has been absolutely fantastic. If if my answers don't give it away, I like to talk. So sometimes I worry about monopolizing the time at these sessions, but luckily they go, the full hour long meeting.

Every second Friday for that one with almost no silence, we have our weekly Wednesday meetings. The CCTX runs same thing. Those are amazing. The level of sharing and communication and question asking that happens really impresses me. I enjoyed a lot. I've, I've learned a lot. And I think there's a lot of really cool things that come out of those types of sharing situations.

And I think anyone who's, Canada or not in Canada, but maybe you're in, maybe you're in financial and FS Isaac is an option to you or something, or, maybe you're a government in the U. S. and you can get into the multi state Isaac or something. I think there's lots of options out there, and if you have these things available to you, you definitely should be taking advantage of them because the amount of intelligence you can glean from them is way more than you'll ever accomplish on your own

Neal Dennis: Hey man, I am, I am fighting hard Elliot to not turn this into a collective defense podcast

Elliot Volkman: mean, go for it. It's yours to take.

Neal Dennis: but, and we'll bring it back around, but

Elliot Volkman: Okay.

Neal Dennis: are presenting.

Without member engagement, without members coming to these meetings, openly discussing things. And let's be fair, it's a Canadian meetup. So nobody's going to tell you to be quiet. They're too polite. But. Getting engaged, having these discussions is what makes those communities at large impactful. You just show up, or for that matter, never show up, but you sign up for a membership, and you're like, give me a feed, and I'll call it a day.

Good luck in five years, or less, because if too many people do that, then there's no quality, because these smaller communities, or these smaller management, with these bigger communities, aren't able to go out and effectively research every nitty gritty thing on their own to impact their membership.

Especially in a community like CCTX, which is a diverse pool of people. It's not just one focal point. So engagement involvement in the communities that you're in. ISACs, ISALs, CCTX, private sharing communities, whatever they are, trust groups. Has to happen for that community to continue to move forward.

And so it's people like Tyler here that, that obviously make that an impact for those communities. So you may say good things about CCTX, but I guarantee you they're, they're way more happy to have you there than, in general because of what you're doing within the community. So that being said, to bring it back after my little rant and soapbox moment A, get your butt involved in an ISAC, ISAL, trust group, something like that.

And if you happen to be in the right industry verticals, get involved in multiple. They'll pay dividends the more you give back into them. But the last piece, back on policy procedure, vulnerability management, things like that. The other thing I love about these, you have people like yourself that are in these communities that have this breadth of knowledge where I can solicit some kind of request for information or a survey, or just a phone call in a group meeting, right?

And ask these questions like we're talking about here. Hey, what's your take on CIS for, for a benchmark? And just like what you, I can get that from you in those communities and, and my ability to grow. Moves beyond my own four walls because now I've got your wonderful expertise to help me.

And so taking advantage of that. So anybody who's listening to this, that's in CCTX, whatever the next call is. You got your vulnerability management guy here. Go harass them. He's got wonderful stuff to share now, flipping this around a little bit and hopefully trying to get us back on track.

Tyler Reguly: I don't think we'll ever get

Neal Dennis: no, no, we're not.

We are way out. When we think about so we talked about benchmarks and the standards a little bit, CIS table stakes, and obviously thinking about your industry vertical to grow this, and we think about uh, prioritization within the aspects of what's available, and then maybe taking that to hopefully leverage that to prioritize your Zero Trust adoption policy and where you need to go.

What other kind of tidbits? So we think about those two big key aspects. What's something else that maybe we should consider along this journey, even if it's just more pure vulnerability management play to remind people again of key aspects here as they grow into that maturation cycle.

Tyler Reguly: I feel like that was like a softball to queue up me saying CVSS, but I'm not sure I want to say CVSS. I one of the things that I think CVSS has done a good job of spelling out, finally, is that it is not a risk prioritization methodology. It is It is about talking about the severity of the vulnerability in context of every other vulnerability.

It doesn't tell you the risk behind it. And I think that's something a lot of people get wrong. A lot of people want to take CVSS and immediately say this represents the risk. It doesn't. And so they, they've got that text in their documentation. So I think CVS is one of those things that you just have to use at this point.

Everyone uses it as a standard. Doesn't matter if you go to a Cisco page, a Microsoft page. If you go to NIST and look at NVD CVSS, CVS, CVS, CVS, CVS, CVS, CVS. is there. It's something that we use. It's something that we can make comparisons with, if nothing else, when we talk about vulnerability against severity, not risk.

We have CVSS v4 out now. If you haven't read it or looked at it it does make improvements, but also adds complexity over past versions also removes some complexity, thankfully no more scope. Although there is. I have issues with the use of the word penultimate in there.

If you go read the entire standard and see penultimate it appears that whoever wrote it thought it meant last and not second to last. So the penultimate provider is who should be giving criticality in some cases. And that seems odd to me. It thinks who I think whoever is at the end of the chain providing it is probably who should really do that.

So that's, that's really my only complaint. I think with before, I think before is a huge improvement. Otherwise over previous versions. And so it's nice to see some, some people start to adopt it. I find the problem and we ran into this problem when we went from, v2 to v3. Now we have the problem with v3 to v4, is different organizations are using, different different versions.

And so we're getting adoption rates that are widely varied. And I just said, and now I'm going to contradict myself. CVS is great because you can use it to do those apples to oranges comparisons because you have something that's standard. When you have somebody who's using three and you have somebody who's using our three dot one, I should say, and somebody who's using four, you can't do that severity comparison as easily.

Yes, it's useful. Yes, use it. Do not consider it a measure of risk and keep in mind that your vendors may not be using the same versions. And you need to take that into account.

I think, the thing to really think about when you're talking about vulnerabilities is the source of information and who's telling you that it's important.

There are in the vendor space who, who benefit from hyping a vulnerability giving it a name, giving it a logo making a web page for it and putting out a big press release that the sky is falling when maybe it's not is, is just financially beneficial to them. There are. media organizations that are happy to pick up and run with vulnerabilities, even if they aren't the biggest thing in the world.

And, then you get something that makes the news, something that your boss sees because it was in a headline in some article somewhere, or, it was on the six o'clock news last night. And they want to know what you're doing about that. And they want to shift all their resources into that because they saw it on the news.

But it may not be the most critical thing for your environment. It may not be the most impactful thing for you. And I like to call it media hype. I like to talk about media hype vulnerabilities. I think that that's something that you have to be aware of when you're prioritizing what you're fixing.

And it's something you have to give a good answer about when you do have your leadership come to you with something that you know. Is being hyped by the media, but maybe isn't as critical as three or four other things that have come across your desk.

Know who your vendors are in your environment and know what they're saying about their own vulnerabilities.

I think that's important. Now, do some vendors try to downplay their vulnerabilities? Of course they do. Anybody who's followed, Loop back to CVSS. Oracle, once upon a time, modified CVSS because they didn't want to use complete when they were talking about a database compromise because it wasn't a full OS compromise.

So they implemented their own in between partial and complete for CIA called partial plus. which allowed them to downgrade what would have been complete, complete, complete to partial plus partial plus partial plus. So vendors definitely do that too. But at least your vendor is going to be able to tell you, Hey, the sky is falling.

This is something we want you to fix right now. If your vendor is not screaming at you, they're not sending you alerts. There's a chance that maybe the media got it wrong because I know that a lot of companies out there, when they think something is serious, They will yell at you. They'll say, Hey, fix this right away.

It's a big deal. And again, I think we're seeing that right now with the Cisco one. And the fact that we've got a massive Talos blog post out covering all the details about it. It's got all the IOCs in it. They've done a great job there and we've got patches out for. At least the known vulnerabilities, the initial attack vector is still unknown, so there's still some risk there, but they are putting it out there, being open about it and presenting it, and I think that's a really good thing to see from a vendor.

I think that's a great example. Other vendors can take away, and it's a way to develop a lot of trust in the vulnerability management processes. If you can sit there and see that your vendor is sharing all this information with you, that's a huge win.

Neal Dennis: And Cisco obviously has a wonderfully new shiny penny for log management services, so they should be able to see more stuff. Yeah, I, I think that's awesome because literally just plus one, the whole entire fact about what we talked about, from a vendor trust relationship, because as an Intel analyst, which the, the, the approach you just described on how to manage that data to make it intelligent for you at a base layer, that's, that's Intel 101. When you consume something from a third party source, I don't care what they label it, I don't care what the feed is called, unless it is purposely curated for your environment by that vendor, and they know you and they're doing this for you kind of thing. That is not intelligence, that is data. And it's the same thing with these with the CVSS, it's the same thing with the vulnerability pages, things like that.

You, I don't go and consume every IP hash or miter framework, fingerprint, TTP, Yara, whatever it is I'm getting from all my sources. I have to prioritize them. I have to rack and stack those things to make them actually intelligent for my environment. And I think for you talking about, vendor trust and relationships around that, that that's a great way to start.

If the vendor obviously is telling you, Hey, you're screwed. Do it now, do it. But if you've got. And some, and a lot of corporate networks and a lot of larger enterprises, they're looking at six, 700 minimum sources of, of software and product that there have in their environment at a minimum. So that, that supply chain aspect of things, and, there's things that are echelons down like SolarWinds was for people, SolarWinds big fricking company, but most people didn't know they had it. And this goes back to. Understand your environment, understand what your company's priorities are to keep the dollars and the lights on.

And then you rack and stack from top to bottom what that is. And then hopefully you understand your bill of materials for those key resources. And then you can maybe start building that relationship with the vendor, depending on the scale of your company. Or at least some awareness within what that factors.

But to your point, There's crap. It's all crap until you've been proven otherwise. And don't just take everything for what the third party says it is. Make it intelligent for you. And then hopefully you won't have to get up at Saturday at 3 a. m. after having a wonderful binger on Friday night to hear your sister yell at you because he read some news article on Ars Technica.

Tyler Reguly: you put that much more succinctly than I did.

Elliot Volkman: appreciate

Neal Dennis: from that vulnerability aspect. So I love it. I think it's. I think it's awesome. I think it's hilarious as well as awesome that you've considered that and obviously deal with that as makes sense.

Like you should. And it's, it's just the the parallels between my life and your life in those same veins is about the same, because you'd get a phone call as a vulnerability management guy. When that Ars Technica blog comes out at 3am, but the Intel guy is also getting a phone call to talk about where, who is actively doing X, Y, and Z while you're getting told to go fix it.

Tyler Reguly: Yep, or write coverage for it as we do. Yes, which is we haven't talked about

Neal Dennis: Oh, oh, yeah.

Tyler Reguly: You talked about, you can't turn on all of your feeds and you can't take every Yara rule You're sent and everything you're given and I just thought about the fact that you know That's that's one of the big things people don't give enough Thought to the false positives that you start to generate when you turn on everything and you just take everything and you just throw all the noise out there and and being in, in that space and, watching, that's what my team does, right?

Is we, we ship the content that powers a VM tool. That's, that's what we've done for, That's what got me into this was starting to write content that powered a VM tool 18 years ago. I've spent a lot of time and seen a lot of changes over time and how you go from something that is quote unquote, false positive prone to a direct condition test.

And I, I don't want to name the software, but there's, there's one example that I absolutely love. And this is, this is just gonna be a pure vulnerability thing, but anecdotally, I find it fascinating. Back in 2014 A product from a very large two letter company had a vulnerability in it that allowed anyone who could communicate with the open port that was just listening by default to execute commands on the host.

It was just there. It wasn't technically a vulnerability because It was a feature that they had put in the product. So it, it came to light, came to the attention of other people. People started exploiting it, exploit showed up in all the popular exploit frameworks for it. It was very easy to take advantage of, and it was, and I'm going to do air quotes patched.

There we go. I got to get them into the frame, but what they really did is they introduced an option to turn it off. So fast forward, that was 2014. I just had a conversation with somebody who installed the 2023 version of this software. And we reported this 2014 CVE on it. And they said, this is impossible.

This is a false positive. And I said, it can't be a false positive. It's a direct condition test. We're actually testing to see if that vulnerability exists. So we ended up getting the software, installing it. And sure enough could exploit it. That checkbox is still there to disable the setting, but it is still enabled by default on the latest version of the software.

And so I guess that's an example of where vendor trust doesn't work, but I think it's a great example of how. You have to know the type of content that you're turning on and running and know if it is something that is the VM world, there used to be this term a banner check. Is, is it a banner check or is it something that's actually testing the condition?

Because, You can alleviate a lot of your stress, a lot of your pain points, and a lot of your back and forth with either your operations team that's involved with dealing it with it, or your vendor by knowing sort of the, the fidelity of the check that you're dealing with. And so I think that's an important thing to throw out there, too, that organizations need to think about is how much can you trust your detection?

Elliot Volkman: the,

Tyler Reguly: a VM problem, right? That same thing exists in the IDS world. It exists in the SCM world. It exists anywhere that you have content or signatures or whatever other term you want to use coming from your vendor. The antivirus world. I there's a Python library that I can't for the life of me install on my computer without turning off windows defender first, and it's a valid Python library but it.

Windows Defender wants to flag it and remove it every single time. So there are, you have to, you do have to consider those things as well and make sure that you have a high level of confidence in whatever you're using for whatever method of detection you're performing.

Neal Dennis: Yeah. I love the the wonderful, it's not a bug, it's a feature response from product companies. Now we meant to, we meant to do that and break the product. So thinking a little far forward then on this. So we. Vendor relations, supply chain, there, there's a whole two hours worth of a podcast just talking about supply chain risk mitigation and how to handle those and build those relations.

And so for LA, maybe that's a fun one where we get a couple of I think that'd be a fun one to have just, someone working at a company vendor side of the house, a couple of people to talk about what they would like to see from their, their client base. That'd be a fun chat. That being said, I I'm curious about your take on, on how often you see someone obviously pushed the patch, but don't test the patch perspective, or how often someone should realize that when they push the patch, they should test the patch.

Tyler Reguly: Yes I like to call this the patch management versus vulnerability management debate. Because those are two very different things and I, I wish I could make more people realize that. All the time. And I've, I've got a few examples. I think the biggest one is just, we'll just say it Microsoft in general.

If you ever take a look at any patch Tuesday and I've taken a look at hundreds of them then you'll know that there are always vulnerabilities that have post patch configuration steps. In order to fully remediate them. And I can't tell you the number of conversations that I've had over the years with people who WSUS rolls out the updates for them.

Oh no, I pushed those updates. Look, the update is installed. That's great. But the update was step one. Did you then go in and apply this registry key that turns on this feature and this registry key that changes this value? And the answer is almost always no. So I think that's a huge one. The best one, and we gotta go back in time a little bit for this, but IIS famously had an issue from Windows Server 2000, all the way up to about Server 2008 ish, where if you were on a service pack, and you, so you, let's say you installed Server 2003, and then you updated to Service Pack 1, you updated to Service Pack 2, Service Pack 2 initially you then turned on IIS.

It would grab those core unpatched IIS files that had come with the installation. It didn't have the replacement Service Pack ones on it. So you could be running Server 2003, Service Pack 2, but your IIS was actually at the non Service Pack level. And so all those IIS vulnerabilities still existed.

And so we dealt with dozens of customers who would come to us and be like, no, no, no, I'm running Service Pack 2. This vulnerability says it doesn't apply to Service Pack 2. But you ended up in this weird state where the service pack was half unapplied and, but because you never tested it, you never even looked to see, do I have the right files afterwards?

I think And I, I just suggested this. So you talked about, great phone calls coming out of, um, like CCTX and other organizations like that. I ended up spending an hour on the phone with another member of CCTX talking about VM and SCM just last week. And one of the things I pointed out, I think an often overlooked feature of FIM, file integrity monitoring, is actually verifying that when you apply a patch.

all your files get replaced properly because that's what a patch usually does in the Windows world is it updates files. If you apply a patch and you have no file changes on your system, you probably didn't apply that patch. Something to keep in mind. So I think there's lots of ways to validate.

Often Windows makes it really easy for you, did the file version increment and often, They make that available for you in file manifest. They're not as accurate since they went to the new patching method as they used to be. There's a lot of blank data in their manifest, but there are lists of file versions out there.

Then you can always check it yourself, check the date, check the file version, check your FIM tool test it, verify with a vulnerability management tool. There's lots of ways to test, but that is a huge problem of people not validating that a patch is properly applied. It's everyone wants the What was it called?

Runco? Runco? Yeah, right? The set it and forget it approach of, of patching and it's not that simple. You have to do follow up.

Neal Dennis: No, that makes sense. I love it. And Elliot over here, trying to chat with us while we're talking. Oh yeah. Fair play. I'm getting my,

Elliot Volkman: guess I'll just chime in. Yeah, we got, we're going to give him the soft exit.

Neal Dennis: gonna call you out. No No, so I I actually don't think I have any other questions to be fair I I think from a curiosity perspective I, I have a rabbit hole that I want to talk to, but not on this call, but I will, I will say for my part, I one find it fascinating that, that you're a part of CCTX and involved.

And I love that. So thank you for doing your part to. To help that community and that engagement. And I'm going to probably be harassing you through Rob, Rick, and Gina. Simply now that I know who you are, so be prepared.

Tyler Reguly: I welcome it. Awesome.

Neal Dennis: And then last but not least, I just iterate on once again, that, I think there's a lot of really.

Cool kind of potential to leverage this type of teaming this, the vulnerability management team and that crew to help build your Zero Trust policy from the ground up, right? Not just to include it as, Hey, when should we patch, but like legitimately take advantage of the work that a team. Of, of Tyler's has done to, to understand the nuances of the infrastructure and understand how to keep from getting a phone call on Saturday morning.

And I think those are key aspects that when going down the Zero Trust pipe, you know, those are questions that you're hopefully asking and, and hopefully don't have to ask. If you have that team already established, or at least not have to ask as many questions around. So I think that to me is one of the biggest key takeaways from, from a pipeline procedural perspective, obviously get you all involved and the sooner I can get someone like you involved at my organization, the less work I have to do to start the rack and stack part of that procedure potentially.

So pretty cool. I'll throw it back over to Elliot and

Elliot Volkman: All right, I've got 1, very short question, which I think you've sort of kind of.

You talked about the why, but let's say hypothetically, you're a strange introverted person and you're a little bit uncomfortable contributing and being part of these communities. What in your perspective would maybe ease people in?

Cause it, these things are established. They've been around for a while, but yeah. Are there mechanisms in place or what is your general thought of like, how do you throw yourself in there

Neal Dennis: join a Canadian community

Tyler Reguly: I, I would say, and I, maybe I talk too much for this to come across, I like to call myself a very shy introvert. I, if, if you see me at RSI, I'm probably the person, not that I'm going, but, if you see me at a conference, I'm the person standing in the corner, usually not speaking.

I don't like to talk to strangers. I, I will talk forever if you start a conversation. But I don't want to introduce myself to you. And that's not that I don't want to, it's that I'm completely terrified of the idea of even considering that. And so for me, I started joining these calls and I sat in silence week after week after week, just listening.

And I, I don't know when a switch flicked for me, but all of a sudden I was, I was sitting there on a call and something came up and I was like, Oh, I can talk. I know these people now. I, they had never heard my voice before, but I had listened to them talk so many times that I felt familiar with them.

And I think, but I think the biggest thing to take away is that everyone at these groups is just looking to improve. They're just looking to better. Their organizations, the community itself. And you are part of that community. So if you can give back in any way and that's how I look at it. I again, I say, I'm shy.

I taught college for several years, developed a number of college courses in cyber security. And afterwards, when that ended, I still mentor I've done some, some teaching for community local teenagers on Intro to Programming and stuff, and all of that stuff is not because I want to do it, because I'm terrified every time I do it, but it's because I want to give back.

And as somebody who's in my position. That is a very easy way for me to give back. Everyone's Oh, that's so great that you're mentoring these people. And I'm like, no, it's really easy because I know it all. I don't have to really do anything. I just get to have a conversation. And so if you're in an area where you're comfortable, everyone else wants to hear what you have to say.

They're excited to hear what you have to say. So just take the opportunity to turn off the mute button and speak up. And it's going to foster amazing relationships because it's been incredible for me every

Elliot Volkman: I love that. That is very similar in nature to why we essentially built this podcast. Plus to rag on really bad marketing and people abusing the Zero Trust time. If anything else, it's a easy networking opportunity. Obviously you. Obviously have been basically in the same org for a long period of time, but there's a lot of movement.

If nothing else being able to connect with your peers and other organizations, there might be an open door for you somewhere down the road. So that, that certainly makes sense to me.

But with that all said it is at the end of the hour. It is the end of our time, but you have certainly covered some things.

That Neal is very interested in and light touches on the vulnerability side. So maybe we'll come back around for around two for some of that. And we'll, we'll build like a panel conversation. So Tyler, thank you so much for giving your perspective. If our listeners are still, jiving along for this definitely check out some of Tyler's work because that your group publishes a lot.

A good bit of stuff and a lot of research. I, I'm definitely well acquainted with some of the research that comes out of your org and it, it generally is really impactful and top notch. So I'll, I'll throw that out there as well. So Heather, thank you so much for being here. Really appreciate

Tyler Reguly: having me. This was a lot of fun.

Announcer: Thank you for joining a Z T an independent series. Your hosts have been Elliot Volkman and Neal Dennis to learn more about zero. Go to adopting Zero Trust.com. Subscribe to our newsletter or join our slack community viewpoint express during the show did not reflect the brands, employers, or companies of our hosts, guests or potential sponsors.

Discussion about this podcast

Adopting Zero Trust
Adopting Zero Trust
Today, Zero Trust is a fuzzy term with more than a dozen different definitions. Any initial search for Zero Trust leads people to stumble upon technology associated with the concept, but this gives people the wrong impression and sets them off on the wrong foot in their adoption journey. Zero Trust is a concept and framework, not technology.
We are on a mission to give a stronger voice to practitioners and others who have been in these shoes, have begun adopting or implementing a Zero Trust strategy, and to share their experience and insight with peers while not influenced by vendor hype.