Effective Vulnerability Management at Scale: Strengthening Defenses Against Cyber Threats

Megan: All right. Welcome, everyone, to our webinar on Effective Vulnerability Management at Scale. Just a couple of housekeeping items before we get started. You'll see a chat function and Q& A function at on your screen. Feel free to use those throughout the presentation. Our presenters will be responding to questions throughout, so please feel free to weigh in and add any comments that you have during the talk. All right, getting started. Here's our agenda here, a little bit overwhelming. Don't feel like you have to memorize it. But this is all of the topics we're going to be talking about today. Getting us all squared away on vulnerability management are our two presenters. We have Greg Porter, who is the founder of Allegheny Digital, and we have Jim Goldman, who is the CEO and co- founder of Trava Security. These two experts will be walking you through the next about 45 minutes of our time and we'll leave some time at the end for questions. All right, I'll kick it over to you both.

Jim Goldman: Thank you, Megan. I'll kick it off. Vulnerability management is one of those loaded terms, often misused or misunderstood terms. People use the term vulnerability management, but nine times out of 10, it's nothing more than vulnerability identification. Therein lies the problem, and that's a lot of what we're going to talk about today. It's one thing to be told you have a thousand vulnerabilities, it's another thing to know, which is the most important of those? What do I do about them? Where do I go to find the fixes for them? How do I fix them? Et cetera. So that's a big part of what we're going to try to demystify today and talk about this entire cycle of vulnerability management, and not just the typical vulnerability identification. Greg will be talking more about the tools that are necessary there. I'll be doing a little bit of introduction to the process. But the fact of the matter is that All organizations, regardless of what business they're in, if they have a cyber presence, if they're handling data, they need to be concerned about vulnerability management and they need to take it seriously immediately from day one. The day they establish a cyber presence is the day they need to have their vulnerability management process in place and well organized. We're going to talk about how to get started on that. Go ahead to the next slide, Megan. This is that the full process and what I was alluding to before, when most people talk about vulnerability management, all they're really talking about is that upper left-hand corner. They bought a tool or they have a service, or they manage service providers, provides a service, and they're able to detect vulnerabilities. And that's the beginning and the end. What has to happen next, as I said with the illustration, that's not so far-fetched that they have a thousand vulnerabilities. The first time they do this is how do they assess the risk, prioritize it, analyze it, et cetera. And the important thing is, through what lens? In other words, they have a business to run. They're not in the business of mitigating vulnerabilities. They have a business to run, they have limited funds, limited budgets, limited people time, limited expertise, et cetera. So it's not necessarily an easy process to decide which vulnerabilities need to be mitigated first. So once you assess it and you get that prioritization done, then we go back to the left-hand corner with the mitigate. Sometimes the mitigation is a patch, updating software, et cetera. Then what you always want to do is you want to retest to make sure the vulnerability is actually now gone. So use the same tool that detected the vulnerability in the first place, make sure whatever steps you took with updating software, so forth, were effective, you retest. Then what happens is you have to repeat the detection, you have to repeat the whole process. There again, I know Greg will get into it in more detail later. But depending what area of your infrastructure you're looking at, you may want to be scanning every 30 days, maybe it's even as often as every 24 hours or every seven days in some cases. I've alluded to some of these challenges already, but one of the big problems is today's environments are so complex a lot of us are using multiple different cloud- based softwares and cloud environments and so forth. So it's very, very difficult to, A, understand what are the boundaries? What's in scope for your system? Which tools are out there to make sure you're actually scanning all of your environment? Once you scan it, as we talked about before, how do you prioritize them? You can easily get overwhelmed with the number of vulnerabilities. I think the bottom bullet point is in some ways the most important, that it's just really poor hygiene and a lack of scanning and keeping software up to date and keeping patches done. That's most often the cause of breaches. It's not necessarily from some brand new vulnerability that hadn't been reported yet. It's most often because of just poor hygiene over an extended period of time. I'll turn it over to you, Greg.

Greg Porter: Yeah, thanks very much, Jim. And thanks to you all who were able to join us this afternoon. Welcome. Delighted to be here. Just to pick up where Jim left off, in terms of defining assets and... Jim, you made a great point. Sometimes this gets lost on us as technologists oftentimes. We're in a business... most of you listening, in a business to make money. You have a unique product, a unique service that generates revenue for your organization, or perhaps you develop intellectual property. There's a real simple question you can ask as a cyber defender, but often I find it doesn't get asked. And that is, how do we make money? So really understanding that's a simple enough question to ask, but to elevate that conversation, do you as a cyber defender at least have some type of intersection or conversation with, for example, your financial business leader, maybe your CFO, or a departmental manager that's tasked with ensuring health when it comes to financial oversight? This could be a chief operations officer. But it's important to have that conversation because once you understand how you generate revenue, what makes your business unique, you can then start to work your way downward and think about, " Well, what assets help facilitate mission fulfillment?" I really like to think of these five key areas when it comes to assets. What do we mean by that? So we think about it in terms of vulnerability management, but really universally speaking, people. So who are the people that we need to operate this organization or to operate our vulnerability management platform, maintain visibility, help us ingest intelligence about our environment? Those people are obviously essential. Then what information are we trying to defend? What's important to our business? It could be intellectual property, it could be other sensitive data sets, perhaps it's healthcare information, something that has regulatory obligations for defending that information. Personally identifiable information of course would be another aspect of that. Then what technology assets are we using to facilitate this service that we want to defend, this application, this mission. Most obvious, this could be a workstation, a server, perhaps a laptop. But really, these lines are now more blurred than they've ever been. For example, if you work for a manufacturing organization, you could have what we call IIOT, or Industrial Internet of Things solutions. These could be different sensors that are automating services, gathering intelligence maybe about an automated production line. Could have sensitive data in there that naturally that you would want to protect in addition to other more traditional IOT devices, IP- based cameras, for example, different sensors you might have in refrigeration units. Then what facilities do these transactions take place in? Now, years ago, this was easy. Well, Greg, I show up to work every day. I have an office that I go into. It's located in Sheboygan or wherever it may be. But post- COVID, this has really exploded. So now we have literally thousands if not hundreds of thousands of remote locations and remote facilities. And that is where are your technology workers and your workforce members are reporting into work today. Often, this is in the remote office from home. So we want to have that mindset of, how do we defend from a physical safeguard perspective? Which we don't really touch on in vul management, but it's certainly a key aspect to bear in mind as we go through our discussion here today. Then lastly, supply chain. Who are those key vendors? This is becoming more and more obvious to us in terms of cloud service providers that we might work with; the Google Cloud platform, Amazon Web Services, Microsoft 365, Azure, et cetera. So thinking comprehensively about what we need to defend, where it may reside in terms of this asset picture is very helpful. Once we have these five categories, now, if we think of that technology and information stack, how do we start to identify these things? I think, Jim, you alluded through this earlier. I think oftentimes there's an oversimplification here. There's the feelgood moment, and the feelgood moment is, " Hey, we acquired a vulnerability management platform." So maybe our good friends at Rapid7 or Qualys or Tenable, we have the wonderful tools that they make, and we start enumerating devices in our production network. But that's only part of the picture. So we have this external internet- facing presence that may contain things like our web applications, web servers, email servers, perhaps into some type of demilitarized zone, our cloud services applications. So there's Azure, M365, et cetera, tenants that we're using. So how are we enumerating those? I mentioned IOT as well. Maybe shodan. io as a useful place to help compliment your volume scanning. But we want to have that inventory naturally and similarly on our internal side, on our production network. This type of intelligence would come from things like our network security appliances, traditional IT routing type devices, our routers, switches, firewalls, web application firewalls. But also, are we logging things like domain name systems? This becomes critically important if we have active cloud tenants in our environment. So you might have an enterprise license for a Microsoft stack, but sometimes given the speed of business, you have a developer who maybe uses a private email address, starts to communicate with the Azure Cloud. If we're logging that transaction and maybe our domain name system logs, our DHCP logs for new devices, we have the opportunity to start to gather that intelligence and, oh, look, we have a new asset on the network. In addition to that, sometimes an area that gets overlooked are the folks that work in IT procurement, that are negotiating new contracts or decommissioning contracts as well. It's a good conversation to have with them or have some linkages as part of maybe your project management oversight aspect of vulnerability management that you're getting that intelligence about what new contracts are maybe online or will be hitting in this quarter and what just as will be decommissioned. I mentioned just in brief that critical question to ask. Well, how do we make money? Well, a great way to understand that is not just ask the question, but also think about your business continuity and disaster recovery processes. Jim and I'll be talking about this down the road at some point. But ideally, you folks have done things like business impact analyses. Why this becomes essential is if we can't defend every asset, because some of you listening may have literally have tens or hundreds of thousands of endpoints. We absolutely need to have good situational awareness and oversight of maybe those Tier Zero or Tier One, Tier Two assets that are most critical to mission fulfillment. First and foremost, non- negotiable, we need to have... to make sure we have good vulnerability management oversight in that regard. I touched on cloud and so forth. Then lastly, there are some of these traditional asset management tools or change management database, maybe something a tool like ServiceNow, for example, endpoint threat detection and response. Obviously very good at cataloging not just what that device is, but what third- party applications, software, command shells, et cetera, may be active on that system. Cloud access security brokers, I don't know if I'd classify that maybe as traditional in a sense. It's an emerging area. But you can think of things like Microsoft Defender for cloud. Are we optimizing the services perhaps that we're paying for? So the point here is that we emphasize at the bottom that we cannot simply rely on our vulnerability management platforms in scanning alone. This is becoming a very complex challenge to organizations to get that visibility and asset identification across our universe of technologies that we're working with. In terms of level setting here, some of you listening may be relatively new to cybersecurity, or you may just perhaps be a business manager and you're interested in maybe some conversations I can have with my technologist, my vulnerability management or cybersecurity team members. So these are really critical terms, but I think sometimes they get oversimplified or not discussed or confused. So just to make sure we're all on the same page, when we talk about a vulnerability, we're really thinking about a weakness, a flaw in a system, a piece of software. A simple example of a vulnerability would be, I'm working remotely in my office. Well, the door to my office is open. Well, that's a vulnerability. I could have a family member come in there, maybe a pet that intrudes. Certainly, don't want a pet or something disrupting this webinar. It's a simple example. But to elevate those stakes, a vulnerability could be a misconfigured cloud service leaking personally identifiable information. Unfortunately, given the speed of business, this happens far too often. You're looking for an example? Toyota recently had some exposures of PII and mapping data, et cetera, that they've been dealing with for a number of years. So it is trying to get good traction and good visibility in this area. Why? Well, because they're threat actors that want to take advantage of these weaknesses. I mean, most of you work for companies that are being scanned, enumerated thousands and thousands of times per day. So these threat actors, they could be internal, an insider threat. But most often, they are external entities, nation state actors, curious, organized cyber criminal groups just looking for weaknesses that they can exploit. And it may be that your organization... Sometimes business leaders will say, "Well, Greg, what do we have that they would possibly want?" On the one side of that coin, you could say, "Well, maybe your interesting information isn't that attractive to an adversary. But you're internet connected and you have bandwidth, and so we can simply use your organization to pivot and attack other organizations." So maybe utilizing a threat intelligence service. Hopefully some of you listening are members of the information sharing and analysis centers, whether it's the Health-ISAC or financial services, the Multi-State ISAC. This is a great way to get intelligence specific to your industry because we have these threats. If we think about this, really this attack surface that we're describing in terms of vulnerabilities and threat actors, a threat is a combination of a vulnerability and an exposure that has potential to produce some type of negative outcome. Now, there's a word that's missing from there, and that is exploitation, right? Exploitation is the convergence of all these factors. And now, this vulnerable web application has exploited a vulnerability and allocate access to maybe some sensitive data that's riding behind that application. Out of these terms, however, a simple question is to think, what can we control as cyber defenders? Well, it turns out we can't really control vulnerabilities because they're infinite and dynamic and technology's constantly evolving. The threat actors have their own motivations. However, the threats that impact our organization; technical threats, physical security threats, administrative, personnel, those tend to be highly similar across industries. So the question then becomes, have we gamified these different threat scenarios to ensure that we have an appropriate security posture and counter measures in place? Vulnerability management, of course, being one of those ways of mitigating and reducing that threat surface. So when we think of effective vulnerability management, we're thinking about threats, vulnerabilities, exploitation. Obviously, an incident management because we're trying to avoid this getting to where it's a material significant incident to the organization. So thinking about this intersection is really holistically approaching vulnerability management as we know it today. Many of you also may have cyber liability insurance policies, but I want to really bring back poor cyber hygiene. Jim, you briefly mentioned this at the outset in real world financial impact. So 10, 15 years ago, cyber liability insurance... and even today, I mean, it's still a reasonable and appropriate thing to do if you're internet connected and you're a profitable organization. Worst case scenario, do we have some contingencies in place that we transfer some of that risk? But given the sheer volume of incidents that we've witnessed or been subjected to that my organization has responded to and Jim's organization has helped insulate and defend companies in understanding where they may have some weaknesses from, there's something called... this thing, deprecated software exploitation, which basically means the cyber insurance companies have become wise to how these adversaries are getting into organizations, and they're really scrutinizing vulnerability and patch management processes. What we mean by that on this slide is that if you have deprecated software, so software that's no longer supported by the vendor, it's end of life maybe a number of years ago or a number of months, and there's an exposure... And so you're thinking, " Well, hey, I have this safe harbor. I have this liability insurance policy. My cyber insurer will help defend me, or at least financially remunerate me in this case," that may not be the case in terms of expectation of financially what you're going to receive. Matter of fact, this is a general chart here, but I've worked with some of these cyber insurance organizations. Essentially, what happens is that the more vulnerable that software was, because it's been deprecated for so long, if it gets exploited based on how long it was deprecated, that may transfer over to how much you're reimbursed. So this is a real- world financial impact. The other thing I'll mention around poor cyber hygiene is, the cyber insurance companies are also looking at your internet- facing security posture. So do you have clear tech services like, I don't know, file transfer protocol, TFTP, Telnet? These things ideally are not internet- facing, but if they start to observe those as well as maybe some poor documentation, they may not even engage and offer to extend a policy to your organization. So again, effective cyber hygiene coming back to mean a financial difference perhaps between you and your competitors.

Megan: Sorry about that. Hold on just a second.

Jim Goldman: No worries.

Greg Porter: We just had a vulnerability exploited, Megan.

Jim Goldman: Okay. Thanks, Greg. That was some great foundational information. So now we want to say, " Okay, I guess I understand a little bit better what this is all about. So how do I get started?" The most important thing... And we do this with all of our customers that are starting on their security compliance journey. It's amazing how many very sophisticated companies do not have a system diagram or do not have an updated system diagram that shows what are the different modules that are put together, what cloud services are they using, how do their customers come in, how do their users come in, et cetera, et cetera. Sometimes it's called a system scope diagram or a system diagram. In different certifications like SOC 2 or ISO, it's often called a system description. But it is a logical diagram. Now, understand the difference between a logical diagram and a physical diagram. We don't need IP addresses and where wires run and everything else. It's just like big functional blocks. Look at it that way. In some cases, you say, what's in scope? What's out of scope? To Greg's point earlier, what is somebody else's problem to worry about the vulnerabilities and what is your problem to worry about the vulnerability? So that's the first thing. You can't assess vulnerabilities and do effective vulnerability management if you don't understand the boundaries of your system and what you're trying to protect. Now, once you understand the boundaries, then it's time to go get a tool. All right? So the tool you need, again, going back to my earliest comments, make sure it's a true vulnerability management tool and not just a scanning tool or a vulnerability identification tool. It needs to obviously do a very good job of finding those vulnerabilities. It needs to fit your scope. It needs to be constantly updated with all the newest threats so that it's finding all the newest threats in your environment. But then it needs to go beyond that, beyond identification, and it needs to give you some insight into how scary is this. In terms of all the vulnerabilities that it found, which ones should you prioritize? That's where the intelligence comes in because you're not the expert, you don't have the time to sift through a thousand vulnerabilities. So the tool itself has to say, " If there were five things you're going to concentrate on, here's the five things that are going to have the most impact for you." It's going to give you the background information to let you know really what's behind this, what's the threat, what's the impact? Sometimes if you want more research, there are things called CVE, so it'll give you links to the CVE. So if you want to read more about it, you can. Then perhaps most importantly, it actually gives you a link to the patch or the methodology to fix it. So there again, you don't have to go out and do research on how to fix it. Then finally, as I say here, you want it to be somewhat automated so you don't have to have someone in your team manually go in and run these scans every 30 days, every week, whatever you want, some kind of scheduling mechanism so you can set it and forget it. So that's the technology piece. So what do you need beyond technology? Well, the way we always like to say is any system involves people, policy, process, and technology. So you have to have the right people to do it. But then what I say here about establishing standards and thresholds for mitigation, that's usually a vulnerability management policy. What I like to say there is that's the what. What needs to be done it so that you know if it's a critical vulnerability. We've got a classification scheme, a risk scheme, that we'll show you the little slide for later. But for your criticals, they need to be done in this many days, for your highs, they need to be done in this many days. Once you establish that standard, that process, you need to monitor the performance. In other words, are you meeting your standards? Now, sometimes you can't, and this is a good point. Sometimes you may uncover vulnerability, it's not your software, it's some other vendors. The vendor doesn't have a patch out for it yet. You're not going to be able to meet your standard. That's fine. But that's when we say you need to manage your exceptions. You still need to document that and monitor the situation so that you're basically in control.

Greg Porter: Yeah. Thanks, Jim. In terms of institutionalizing a vulnerability management process, " So Greg, this sounds interesting. It sounds important to my business. Thanks to you and Jim. How do I get started? What's maybe a methodology or a framework that I could follow?" So my friends at SANS, we have this prepare... this PIACT model; prepare, identify, analyze, communicate, and treat. It gives you this continuous cycle that you're looking at. Preparation is I meet with my internal stakeholders, I talk about the intent of the plan, and do we start to draft at that point a vulnerability management procedure or standard? Now, you're thinking, " Hey, that sounds like a good idea." The question is, do we have a vul management procedure that would detail things like risk exceptions, internal service level agreements for if we have a critical or high level vulnerability? What's our internal SLA for remediation? Is it defined in days or weeks or months? We want to be very precise around those things. Again, there are going to be exceptions, so we should have a workflow for that as well. Jim talked about it, the identify component where we define the program scope. What's our boundaries for what's considered in scope of our vulnerability management program? We may have some key third- party service providers that we cannot just start outwardly conducting vulnerability scanning exercises against given the sensitivity of the assets that they're managing or the data that they're transacting on our behalf. So we want to have explicit authorization whether we're permitted to do that or not. Then we will iterate on this scope maybe as we identify and bring in new services into our organization. We mentioned this manual and automated process behind that. So your tools are going to be very useful for automated discovery and enumeration of common vulnerabilities and exposures of CVEs. We hear the term CVE, you are thinking basically software- based weaknesses. But there's another side of that coin. They're called CCEs, common configuration and enumeration weaknesses. So most tool suites by default will do CVE scanning, but they're not necessarily going to do CCE scanning. So that might take some automated analysis and triaging by your subject matter experts internally. Naturally, we want to have the ability to communicate our findings to key stakeholders and we really want to be as mindful of, how do we communicate those indicators to our constituency? We're not going to go in with technical details about the CVSS score or what the weakness is and start talking to board members and business leaders about that. We want to think financial impacts. So we have maybe some operational metrics for our program team, maybe some contextual metrics for the folks running the tool set. Then we have executive or board level metrics that we want to get up programmatically to that level when it's needed. But we need to decide what those would look like prior and then get into treating and remediating vulnerabilities. Now, if you look at something like this and you're like, " Well, geez, that seems like a lot of considerations, Greg. Where could I go for some additional guidance?" Might be a fair question to ask if you're thinking that. One of the first resources I'd like to look at as a cyber defender would be the center for Internet security and the CIS Critical Security Controls. Here I'm thinking about asset management, CIS control, number one. Really one through seven gives you a good indicator of maybe some considerations that you want to be mindful of for your vulnerability management program. Now, there's 18 currently. So think about, what does our security posture look like in terms of basic cyber hygiene against those 18 control families? We have limited time, limited budgets of course. This is a big challenge for organizations. I've mentioned some companies that we work with have hundreds of thousands of endpoints. And the causes of vulnerabilities are constantly changing and dynamic. They can't patch every single system, mitigate every single vulnerability. So how do we give ourselves as cyber defenders a fighting chance? Then just really to think about this intersection. If we look at the universe of all known vulnerabilities, we might look at something like the NIST NVD, the National Vulnerability Database, which contains CCEs, CVEs. It's a lot of data and intelligence in there. However, not all those vulnerabilities apply to our universe of assets. So when we do our vul scanning, that's where it becomes critical. We start to align this. Where we want to begin is maybe those Tier Zero, those Tier One assets that we have vulnerabilities on those assets. Most importantly, where this really becomes a heightened point of conversation is if that vulnerability is exploitable. So in the public, there's a toolkit or a piece of software that exploits that vulnerability given the adversary or the insider access to that asset potentially. Furthermore, is it under active exploitation from a nation state actor or a cyber criminal gang? Just one thing to keep in mind, I mean, it may be that the cyber criminal gang isn't after your intellectual property. They just want to breach your organization and sell that access to other interested parties. Those are the vulnerabilities we want to mitigate first where we have this intersection. So the question is, " Well, Greg, how do I find that intersection?" Right? Well, we talked about these vulnerability management platforms. Here I have an example of Rapid7, which is a platform that we've used through the years. We've also used Qualys and Tenable. They're all high fidelity, great products. A lot of good software engineering goes into them. But here's our taxpayer dollars at work. So the Cybersecurity and Infrastructure Security Agency, CIVA... or CISA rather, they came out with something called the KEV. They released probably a couple years ago, give or take. This is the Known Exploited Vulnerabilities catalog. Now, they update this daily and weekly. Basically, what this feed is, out of the universe of software- based vulnerabilities, what are being actively exploited? I want to know that as a cyber defender, of course. Now, you can integrate this intelligence. You can either do it manually through a CSV file that they make available on their website. But the platforms that I've mentioned prior are integrating this intelligence right into the database itself. Now, that doesn't mean it's automagic, and hey, I can just... At the end of the day, it's a keyboard and not a magic wand. Am I actually utilizing this intelligence in my vul management platform to help me start to elevate and prioritize and get some additional contextual elements in terms of what I should be focused on mitigating now in terms of my assets that I'm defending?

Jim Goldman: Thanks very much, Greg. Again, talking about industry standards, this is the industry standard chart that I was referring to earlier in terms of criticality or severity. So how should vulnerabilities be rated in terms of severity, which was obviously leading to prioritization of which one should be looked at and mitigated in what order? So this is the industry standard rating system. These are the scores that show up or should show up in your vulnerability management system. This is the scale that we use in the Trava platform for our vulnerability management. So this is what our customers see. Again, so what do you do with this? So this is the tool, this is the standard rating system. Then as I alluded to before, you have to have a policy. You all have to decide what makes sense for you. We will mitigate critical vulnerabilities in 48 hours, whatever, you decide that. Then your procedures are, how do you do that? In other words, who's going to do what, when, with which tools? Once you've defined those numbers of days that you're going to give yourself to mitigate each of the different severity types, you then have to have obviously the resources in place to do that. But maybe even more importantly, you have to have an easy, not cumbersome, process in place to monitor your performance to those standards. Are you meeting those expectations? Then anytime you don't, as I alluded to before, there are circumstances beyond your control. You need to manage those exceptions because in many cases, it's the exceptions that'll get you.

Greg Porter: Yeah. Jim, just one thing to add to this. This is a great internal SLA framework maybe to look for and use as inspiration. Sometimes clients will say, " Well, Greg, we're really focused on those critical vulnerabilities, those CVSS scores of 10." But in reality, most of the exploitation that's going on are exploiting vulnerabilities in that medium to high range. So my point is, team, when you're thinking about your internal SLAs, it's great, of course, we want to remediate those vulnerabilities as quickly and as efficiently as we can. So we want to have tight timelines around critical vuls naturally. But also I would say challenge yourselves around those high and medium vuls. What I see is sometimes organizations will, " Well, Greg, it's only a medium vul. We're going to give ourselves six weeks to take care of something like that." But it turns out, in the wild, it's undergoing active exploitation. So it's easy sometimes to just prioritize based on criticality with our SLAs. But what we're seeing from the trend data is those moderate highs are most often the vuls that are getting exploited.

Jim Goldman: Excellent point. This is only one data point. This is only one criteria. Understand that severity is not the same thing as risk. What Greg's talking about is the bottom line risk, and you need to consider other factors in order to determine that risk.

Greg Porter: As we're winding down, how do we engender some adoption by additional stakeholders outside of maybe cyber defenders and the technologists that are part of the program? So institutionalizing effective vulnerability management. It's got to be organizationally bought into. This is where I think the linkage is into your program management office. Your PMOs can be so effective that they help you reach out to that constituency. Who are those key stakeholders that need to be at the table as we instantiate this process. With inception, if you're just lifting this thing off the floor and looking to get a vul management program going, you want to be realistic in your expectations. You have limited budget, limited staff. So what can we look to achieve over the next six to 12 to 18 months? Then we want to iterate and build upon that. I mentioned earlier establishing some realistic goals monthly, quarterly, and annually. And I'm saying in addition to that, establishing some measurements behind that, maybe some business and executive base leadership metrics, operational metrics for maybe the management teams, your system owners, your application owners, your software development engineers, the DevOps teams, et cetera. Then your more contextual metrics that the internal vulnerability management team members are using. This is ideal, to have an established, dedicated vul management team as opposed to adding additional responsibilities. I know many of you are probably wearing multiple hats. " Hey, Greg, I'm going asset man., vul management, configuration management. I'm also running cables, connecting routers and switches, fiber optics, et cetera." I understand that. And there's only so much you can do at the end of the day. But at least you're acknowledging the importance of vulnerability management. But eventually, as the company hopefully becomes profitable, in large part... thank you very much to your efforts, you can start to expand that team. That's where some of these fundamentals that Jim and I are talking about become essential. You might know what you're doing when it comes to vul management, but how do you maybe convey what your expectations are to an intern or a new hire? That's where having your vulnerability management process, your measurements decided upon, you're iterating, improving based on lessons learned, but you want to have that documented. I mean, I see many organizations that just time after time want to throw a tool at this problem. A tool in the absence of process is just doomed to fail. Trust me. Seen it many times. Jim, I'm sure you would agree.

Jim Goldman: Absolutely.

Greg Porter: Yeah. Then just winding down here, team, it's wonderful when you can create incentives for process improvement. Your responsibilities as a cyber defender when it comes to vulnerability management are identifying risk in that asset. It doesn't mean that you identify it, that you go in and you patch it, you reconfigure the system. Ideally, you identify that risk, you transfer that knowledge, that information, create a ticket that gets routed over to maybe that system owner, that business process owner, you have the corrective action recommendation in there in line with your SLA. " Hey, Sam. Here's the vulnerability we found on that DevOps server you're working on. It's a high vulnerability. The expectation is you'll have that remediated in two weeks. Can you just let me know when you close this ticket?" Of course, through automation, you would get that alert anyway, but you get a general sense for the workflow that we're looking for. So recognizing and rewarding achievement. So if Sam takes action time and time again over those requests and they're owning the vulnerability weaknesses in their environment as a business owner, financial incentives, recognizing them amongst your constituency, your workforce members are valuable. Then what happens over time when you recognize them, what I've seen is they become security champions. They become your best advocates as you start to iterate on this program. The last thing I would say is, start with a proof of concept. In other words, if you have 5, 000 assets, don't come charging out of the gate, " We're going to scan everything, rate out all 5, 000," because things might not go as you're planning. Systems might burp, a process may go down, a server, for example. So begin with maybe a small test enclave, let's just say a hundred or so workstations or servers, whatever it may be for your environment. Do some testing in that environment, talk with those people beforehand. This is where your PMO becomes very important. Establish that trust, debug the process. And as you get good fidelity around, hey, we've operationalized this, we're feeling good about things that we anticipated weren't going to work, we solved those problems, and then we start to move it out, the next 200 assets, 400, et cetera. So by the time you get to that end asset, you've really addressed a lot of those stakeholder concerns by then.

Jim Goldman: Hey, Greg, just extending on the process side, I know something you're particularly passionate about is communication to board of directors about security program posture. Clearly, it's not appropriate to give a vulnerability report to a board of directors. But can you just talk a little bit about why is involving the board of directors important first and foremost, and then secondarily, what kind of output out of your vulnerability management program would be appropriate to communicate to a board of directors?

Greg Porter: Yeah, sure thing, Jim. I think from a board perspective, a lot of what we're seeing that's happening in the industry right now is around disclosure regulations. If there's an exposure, how quickly did you identify the weakness and disclose it to your shareholders and board members? I would say from my perspective, boards are more curious than they've ever been about cyber- related metrics and instrumentation. Where vul management becomes important to the board is these are the people that are tasked with fiduciary oversight, preserving mission fulfillment, preserving how you make money, advising your senior executive team on maybe novel concepts or things that they've experienced over the years to give you a market differentiator. Vul management becomes critical in this discussion. So if you can envision a discussion with the board, and maybe you have your top five risks that you've identified, and so your security liaison is communicating with the board and you say, " Here's our top five risks that we've identified. Here's the cost if we have an exposure. Here's the corrective action and here's the cost to correct." Right? It's in very clear terms. The board now understands these people are cyber defenders that we're paying, are interested in preserving our financial solvency. Right? But if you're not having those conversations, if you're not engaged with things like... And there is some artful crafting to this, Jim. It's not just, " Let's send them a bunch of metrics." The point is you want to talk with your CISO, your security leaders well before you're ever in front of the board presenting any type of information. You would want speak with your chief operations officer, CIO. You're like, " Greg, those are busy people." Yes, they are, but try to get maybe 30 minutes on their calendar. Have a cup of coffee with these folks, tell them about your vulnerability management ambitions, where you're trying to get this program through. So by the time you get to that leadership meeting and those board presentations, Jim, you've really debugged that process and you know what those board members are looking for from an appetite perspective. But yeah, that's generally my thoughts on a minute or so on that.

Jim Goldman: That's excellent. We're starting to see a trend where... I think right now it's best practices. It may be become more regulated or required in the near future to have a designated board member that has expertise and background in cybersecurity.

Greg Porter: Yeah. In fact, the Securities and Exchange Commission, Jim, just late last week came out with their ruling on that. We were all hoping as cybersecurity practitioners that they would explicitly say you needed a director with cybersecurity experience. They didn't go that far. They retreated a little bit on that. However, they talk about cyber risk oversight and just the board aware. So for those of you listening, in my opinion... This is just Greg's. And Jim, I know you agree. Now is the time to enhance cyber literacy at that board level, certainly at the executive level. Don't wait for the next SEC update coming down the road, which I think it inevitably will, where they'll say, " Hey, we're desiring directors to have cybersecurity expertise." I think that's inevitable at some point. Even if it never occurs, it's just good business sense and good operational security to have those types of conversations, have that intelligence at the board level, and of course at the executive level, if they're informed enough to have those detailed conversations when needed and ask the right questions, meaning your board members are challenging your C- suite when it comes to cyber.

Megan: Those comments actually roll into a question that came in that says... on that same vein, is, " How do you see vulnerability management evolving in the next few years? And what emerging technologies or practices do you believe will have a significant impact on the field?"

Greg Porter: Yeah, that's a great question. I mean, I'd be happy to take a run at that initially. So how do I see vulnerability management evolving? When I started in this industry over 20 years ago, we would show up to a client, we would have our vul management platform literally running on our laptops, we would connect to the network, and chances are we could scan all those assets that were in scope for that client at that point in time. Those days are dead and gone. What's changing is now this deployment into the cloud that's transferent of assets from maybe the traditional on- premise data center into the cloud. So I would say for those of you listening, you might have very good awareness of assets that are on your production network. But how do we feel about the APIs and the data sets and the applications that we're running in our cloud environments? By the way, we're starting to get into situations where that CCE component really focusing on those cloud tenant configuration security baselines are absolutely essential. That's oftentimes not going to come out of the gate with your vul management platform. There are companies like Wiz, I think a Dome9 with Check Point now that can offer those types of configuration standing ability. So I do see that shift. And that's not going to change. I think it's going to get more prevalent into the cloud. The other aspect, I think, that's going to be evolving... and of course I need to say this as a buzzword, what would be this intersection of machine learning and artificial intelligence. I'm hopeful that we can get some good integration with our vul management platforms. I mean, we're certainly seeing aspects of that on the threat intelligence side. I know the Qualys of the world, the Rapid7s, and Tenable are looking to integrate those processes where it makes sense. But I'll just conclude my thought with this. Never forget the basics. Regardless of how we evolve with AI and ML... And we will. Of course, as we all know, technologies waits for no person. But if your patch management ain't real good and your vul management ain't real good, and your configuration management... pardon my pun here, but isn't real good, chances are you're going to have an exposure. And those are tried and true principles that we've been aware of as technologists for 50 years, 40 years at least. So are we getting the fundamentals right before we start thinking about the next nuanced shiny object which we want to ingest and make part of our program? And I think sometimes it's a challenge to proxy ourselves as technologists and say, " Well, wait a minute. How are we going?" If I'm having good measurements and good metrics behind those fundamentals, then I think it's good and warrants maybe some of the adoption of some of these emerging areas. But a good question.

Megan: We had another question and a comment that says, " Investments in cybersecurity need to be an important part of investor relations and ROI. Is there a way to quantify or measure ROI in cybersecurity in company's earnings reports?"

Jim Goldman: I'll take the first crack at that. I don't know that it could go into company's earnings report, but I think it could definitely be a discussion at the board of directors level. There's a couple of areas of data that continues to grow and be more and more refined. There are metrics around cost per data record breached. That is a particularly good metric in my opinion because all companies are not created equal. You could look at breach costs even for a vertical sector. But even there, there could be a wide range of difference because strictly of the amount of data or the number of data records that one company holds versus another. The reason being is obviously the more records you hold, the more customers own that data, therefore the more customers that could sue you or hold you liable. Therefore, that's the scale and the cost. So it's not so much return on investment as it is. I do think there's data out there that could say, " if our company were to have a breach, based on pretty good data that's out there, here's approximately what our loss would be, could be, et cetera." Now, that quickly branches into cyber insurance. In other words, if you can compute your highest possible loss, then you have to say, " Well, what should the aggregate limit of our cyber insurance be? Therefore, how eligible would we be for cyber insurance with that aggregate limit and how much would it cost us?" Well, the cyber insurers have gotten smarter, especially with the terrible ransomware breakout of a couple of years ago. They're now a lot more interested in, for example, your vulnerability management program and other specific control areas like multifactor authentication, backup and restore, security awareness training, et cetera. So my short answer is, yes, we can put some financial numbers around potential loss, but I don't think there's yet a... And I'd be interested in Greg's opinion. I don't think there's yet a great correlation between if I spend a dollar on a security tool, I'm going to get this return on that investment.

Greg Porter: Yeah, Jim. Thank you for those thoughts. John, that's an excellent question. I think a couple things that least come to my mind. I think as security practitioners, security professionals, approaching... And not that you're suggesting this. But talking to leadership and looking for this swan or this albatross that has return on security investment, this rosy term that a lot of us have been trained on, I think that's a challenging conversation. I'm just not convinced that that's the right way to go. What I like to think of when it comes to conversations of financial spend is... For our business, we look at this as the cost of risk reduction. So we're making an investment in technology or personnel or some type of safeguard to reduce our enterprise risk. So I know it's a small nuance, but I find success when I'm talking to executive and board stakeholders talking about the cost of risk reduction. Where do I get some of these data points? Jim mentioned things like the Ponemon Institute and their annual breach reports for some financial metrics, the Verizon DBIR, the Data Breach Investigations Report, has been a terrific resource for years. What I like more recently, what Verizon has been doing is taking the DBIR report and looking at exposures that organizations are being impacted by, and then aligning that to like the CIS control family. In other words, if I have a limited budget, which most of us do, where should I start prioritizing my defensive countermeasures based on what's actually going on in the real world in terms of how the adversaries are getting in? Website exposures and exploitation, insider threats, et cetera. And I can start to prioritize or my investment decisions in line with what I'm seeing from an empirical evidence point of view. So just a few resources to keep in mind. Jim, I wanted to... I'm having a little bit of brain fog here. But I know there's an insurance industry document that comes out annually that looks at the cyber insurance market, that talks about what are the average costs for attorney fees, IR retainers, incident response for your technical defenders. I want to say Bitsight, but... I'm sure it'll come to me after we conclude the webinar. But Megan, I can-

Jim Goldman: Yeah, we can post it afterwards. Yeah.

Greg Porter: Yeah. It's just for some reason, John, I can't remember it off the top of my head. But I've cited it many times. But I can get that resource to you all. Great question. Any other questions?

Jim Goldman: Back to you, Megan.

Megan: Yeah, as we wrap up here, that was a wealth of information on vulnerability management. I just want to make sure everyone here is invited to the next webinar in this series on business impact analysis coming up in September. So this recording, I know it was a lot to take in, will be sent out after this concludes along with the resources I posted, some additional reading in the chat, as well as links to Allegheny Digital's and Trava's websites if you want to learn more about what we do. Hopefully, see you next time at the next event. Any other concluding thoughts, Greg or Jim?

Greg Porter: Yeah, Megan. I think that company I was thinking of was NetDiligence-

Jim Goldman: There you go.

Greg Porter: ... andtheir annual cybersecurity reports. So John, that might be a resource in addition to the DBIR and Ponemon reports where you can start to mine some intelligence, maybe add some data points to your conversation around financial metrics, investments, et cetera.

Megan: Great.

Greg Porter: Lastly, I would just say, team, if we can help, you can find Jim and I on LinkedIn. As we like to say, opinions are free. There's no charge for that. So please, we're all part of the same community at the end. We're trying to defend our businesses against all this adversarial activity.

Jim Goldman: Absolutely.

Greg Porter: We all learn as a community. So certainly feel free to look us up on LinkedIn. Okay?

Jim Goldman: Thanks, everybody.

Megan: Thank you both.

Greg Porter: Yeah. Thanks, everybody.