https://cisoseries.com/why-ignoring-most-of-your-vulnerabilities-is-the-best-strategy/‘
Which vulnerability should you tackle first? Second? Which ones should you ignore? Probably a lot more than you think.
On this week’s CISO/Security Vendor Relationship Podcast, David Spark of CISO Series and I welcome sponsored guest Ed Bellis, CTO, co-founder, Kenna Security (now part of Cisco) to discuss vulnerability management among many other issues.
Full transcript
Voiceover
Ten second security tip. Go.
Ed Bellis
Leverage security talent across your organization from non security people. Looking for somebody to work in AppSec? Leverage your development team. Looking for somebody to work in Cloud security? Look at your DevOps team. There’s lots of transferable talent.
Voiceover
It’s time to begin the CISO Security Vendor relationship podcast.
David Spark
Welcome to the CISO Security Vendor relationship podcast. My name is David Spark. I am the producer of the CISO series. And joining me as my co-host for this very episode is Andy Ellis. He is the Operating Partner over at YL Ventures. Andy, the sound of your voice, let us hear it.
Andy Ellis
Four score and seven years only.
David Spark
Oh you have no idea, those listening. We do an audio test before we begin. And Andy always does the Gettysburg Address at the beginning of our audio checks. And I cut him off, usually about four seconds in. But he always challenges me as to whether I would like to hear more of it. The answer is no, because I could just read it at any time I want to.
Andy Ellis
But then you do not have it in my voice.
David Spark
But Ed, our guest today who I will be introducing, well he wanted to hear it. So we actually got to hear a lot more of it than we normally want to. But if anyone actually wants to hear Andy Ellis recite the entire Gettysburg Address, which can you do it in its entirety Andy?
Andy Ellis
I would have to do like a little bit of prep to not stumble over it. But I think I can do the whole thing in its entirety with about an hour of practice.
David Spark
Alright. We are available at CISO Series dot com. Our sponsor, who has been truly one of the most spectacular, if not the most spectacular sponsor of the CISO Series, Kenna Security. And they are actually now part of CISO, to which I mentioned to our guest that I want to take some credit for that.
Andy Ellis
Most of the credit, not some credit. Do not sell yourself short.
David Spark
And our guest actually said you are not asking for enough credit, which I agree with him as well.
Andy Ellis
You did get that check in the mail.
David Spark
I do actually get checks in the mail from you. Regardless. But not from CISO during the acquisition by any stretch. Now, this episode is dropping February 1st for those listening on the day it drops. We are recording this considerably earlier than that. But this is the Tuesday before RSA, with all health issues hopefully staying calm, Omicron not blowing up by now. We will all be at RSA. Andy, let me ask you, what is your most favorite part of RSA and your least favorite part of RSA?
Andy Ellis
I think my most favorite part of RSA is sometimes going home.
David Spark
That is not good.
Andy Ellis
Although this year I have to have a contingency plan to instead of coming home, go to LA, since the Super-Bowl is right after RSA. Which is, I have got to say, very strange. I actually really enjoy getting to hang out with people, like in small venues. I really hate the parties. You will not find me at basically any parties. There is one I drop into, which is the Wild Ventures party because I kind of have to. But the rest of it, if you want to find me at RSA, I am going to be in a coffee shop. A hot pastrami sandwich at Wise and Sons. If you have not done that yet, that is what I recommend there at the contemporary Jewish Museum, just north of the Moscow News Center.
David Spark
So, you will find this interesting. At my synagogue in San Francisco we actually had three owners of three of the Jewish Delis in Francisco come and speak at the synagogue. And they have a tasting platter which was phenomenal. So, I got to taste pastrami from all the different ones. But, what was really fascinating is they talked about the difficulties of running a Jewish Deli. And why they have to charge so much more for a pastrami sandwich because it is not loaded with a ton of vegetables like a turkey sandwich is. It is all meat in there. And also the difficulties of when they get the food delivered and when it is bad food and they cannot complain about it, get their money back. It was a fascinating discussion about the difficulties…
Andy Ellis
At Wise and Sons they have like a crispy pastrami. It is almost like a bacon that you can have added to the pastrami sandwich. It is so good, I really recommend it.
David Spark
Very good. Alright, enough of this discussion about pastrami, which it is making me extraordinarily hungry. And you cannot find a lot of good pastrami in a lot of parts of this country for that matter. But there are a few places. But I am thrilled to have our guests on because I have had him on many times on our video chats. A few times on the podcast. They have been phenomenal sponsors of the CISO series and I am thrilled he is back here again. Our sponsored guest, Ed Bellis, CTO and co-founder of Kenna Security, now part of Cisco. Ed thank you for joining us.
Ed Bellis
Thank you for having me, as usual.
Hey, you are a CISO. What is your take on this?
00:04:59:21
David Spark
The White House is calling on the Cyber security Infrastructure Security Agency or CISA to establish a strategy for automating the collection of federal agencies’ cyber security metrics by April, as reported by Fed Scoop’s John Hewitt Jones. The purpose of this is to increase the transparency of company’s or Federal organizations, security postures, automatically grade organizations with a compliance scorecard, and have much faster, hopefully automatic, incident reporting. According to the Office of Management and
Budget, “a set of metrics based on NIST Standards for controls that can be reported in an automated manner.” Up until now, everything has been done very manually through forms. Question, for you Andy first. What would be the data that would need to be collected? Could we actually form some type of logical understanding of a organizations risk or compliance posture?
Andy Ellis
So, I have got to say Jen Easterly, god bless her because boy is going to need to do some real work to get something like this successful.
David Spark
This seems pie in the sky does it not?
Andy Ellis
I was reading the thing about what they strategy must include. So it is like, hey CISO, go form a strategy. First of all there is not a strategy. There might actually be a good reason why. But it included things like I think my favorite was machine readable, automatic security instant reporting, which is part of the bedrock of zero trust IT architecture. So, if you did not think that zero trust had yet jumped the shark, let me tell you…
David Spark
I know everything now is a part of zero trust.
Andy Ellis
I have databased it in real time as being updated with everything that you think an adversary might be doing, is the antithesis of zero trust. Because the adversary gets access to that database, assuming it could even exist. I have been on working groups for 20 years trying to figure out how do you move incident data in real time in an actionable fashion. And without context it is basically mostly worthless. The value that many of your security vendors have out there is that they are able to spend researchers looking at your incidents to figure out how that is relevant to a different on of their customers and vice versa. Doing that in an automated fashion without those human researchers I am skeptical but I wish her luck.
David Spark
Ed I throw this to you. Can this be done?
Ed Bellis
Yes I read this with a little bit different lens. And I agree with you that if you kind of took it word for word literally, it is very pie in the sky and full of grandiose words and vision. But then I thought about some of the folks that I have talked to who work in some of these agencies and thought, actually what I bet they are doing is they are automating what is already being manually collected and probably sitting in a million different spreadsheets today. It is probably compliance control, audit findings. It might be, not alerts, but things that have actually bubbled up to actual security incidents that humans have already taken on. And they want to put this in some sort of machine readable form, collect it automatically, centralize it automatically. And it is largely a compliance effort.
Andy Ellis
Yes, I think you are right. That is a much more charitable way to look at it.
David Spark
Well, if they could automate compliance, that would be phenomenal right there.
Andy Ellis
Right, but the problem is it is not really automating compliance. It is automating complying with the control that all your reports are in one place. And the challenge with that machine readable tag is often when you have a new and novel incident it does not fit into the tags that you have pre-defined. You can say here is what an incident was shaped like and if you do not allow a user to say we are looking at the Sony Pictures hack and we need to talk about this whole new concept about North Korea complaining about a movie. If you do not have a place to put that, that is just going to get discarded and lost and that is a problem I have seen in a lot of incident reporting systems. Is they are like what is the root cause? Well I have 12, which one do you want me to pick?
Ed Bellis
They are going to label it with 12 different Mitre attack labels is my guess.
Andy Ellis
That is my worry. So I think it is possible but I worry about the actual value that it will have.
Ed Bellis
Yes I do not disagree with that. I would say to your point, David, anywhere where I can automate compliance, and even if it is complying with the compliance rules, so, ultimately what you are trying to do is generate artifacts that are automatically taking this part of your normal operating procedure. It is way easier said than done. It actually reminded me, 15 years ago of S-CAP. We talked about all of the different things associated with S-CAP. And how do you automate all of these procedures around it, using all of this machine readable stuff? I do not think we are there today and that was at least 15-ish years ago.
It is time to measure the risk.
00:10:01:00
David Spark
What are the metrics that matter? Ross Young, CISO at Caterpillar Financial Services has a list of important metrics. As he has classified them. He categorizes them by processes, people, and technology. Taking a look at his list, which includes defect density, application risk assessment, software defects, expired risks, and offline backups, just to name just a few, I will start with you Ed, which of these metrics do you find the most valuable to determine the health of a company?
Ed Bellis
I looked through this list, nothing really struck me as using any sort of – I am a big fan of using outcome data or round truth data – to basically measure back. To say okay, here are the things that we are doing and by doing these things it is providing this sort of outcome. To me it looked like a list of activities, or we often say best practices in our industry, although I would refer to best practice as more like common practices, because if you are not using the outcome data you do not know if they are best or even if they are working.
David Spark
Also if they are best you do not need to fix them.
Andy Ellis
Yes just align a set of practices and call them the best. I have looked at things like defect density, average age of vulnerabilities, things like that actually kind of grain against the core of what I think about. I am all about measuring the risk, what is the likelihood of this event happening and what is the impact of that event happening? And none of that really related to me.
Andy Ellis
Well here is actually my favorite one. The average age of vulnerabilities, I actually think is an awful one. Because it is high in critical vulnerability. So let us imagine that every server in your environment has a critical vulnerability that is 100 days old, the average 180 days old. We are recording this right after Log 4J comes out. So Log4j comes out and everyone of those servers now has two vulnerabilities but the average age just dropped in half from 180 days to 90 days. That is all you need to look at. This metric does not mean what you think.
David Spark
And also do you need to fix a 100 day old one or do you need to fix Log4j?
Ed Bellis
Exactly right.
Andy Ellis
And reading this metric we say oh ignore Log4j. We have got a backlog, let us fix that first.
David Spark
First of all in Ross Young’s defense, and Ross by the way is a great guy and we have had him on the show, he has a podcast he pre-produces called CISO Tradecraft and he goes into great detail. But he really was looking for feedback on this stuff. He got a lot of feedback, which is great. And it was designed to be like here is a draft, what do you guys think, what is your take? So, I think what he was looking at is things that he could easily measure. I think that was also the thing. And to show improvement on those things. Does that in any way show health, in terms of ease of measurement?
Andy Ellis
He had one in there that I did like because it was in that right direction, which was about the application risk assessment. It was the percentage of applications that can meet every major control that you list in your policies. And I really actually liked that one because that one gets to the heart of what good metrics are. Which is you have decided as a business how you are going to operate. So, lets take the vulnerability one because this one is often easier for people to talk about. If you have said that for high applications, you know the critical production apps, that you will patch critical vulnerabilities within 30 days. Now, all that I want to know is what percentage of the here were you within SLA? Or what percentage of systems are within SLA? And I expect you are within SLA 85% of the time. That is my target number. So tell me how close you are to that 85%. How often are you actually doing what you think you are supposed to do? Because that is what matters.
David Spark
Let me toss this to you Ed. Does that sound like some of the sort of filters you can apply when working with your tool and security?
Ed Bellis
Yes absolutely. So, we have the concept of SLA’s within the tool itself. As you would imagine they are all risk based and risk centric to Andy’s point. Because I do not care about this vulnerability that no-one is exploiting that has little to no impact, could be informational. I could let that remain open forever and it would not matter. I need to focus on the stuff that is going to ultimately end in some sort of event for me. So, you have this concept of SLA’s and it is all based on risk, and the risk is associated with the vulnerability, but also the asset and it is connectivity and things like that. But ultimately what Andy is getting at here, which I think is right, is SLA adherence. Assuming that the SLA that you have built is a function of the outcome data, the risk that we talked about earlier, then SLA adherence actually matters. And measuring that over time and improving that over time matters. So it is really depending on what that is based on. Now, if you just had an SLA that was a little bit more generic than that, and I had to fix everything within 180 days, maybe that is less important.
Andy Ellis
I like to look at it as what is the CISO reality score? If the CISO was asked please describe the security controls of the company, and they are going to describe them to you as the board member, how close to reality is that description? That is actually what you metric should be. We say we do patching, it is whatever the interval is. How close to reality is the CISO?
Ed Bellis
That makes sense because then you are basically measuring what you are actually doing, which is good. Now, again, the big assumption there is that you have all agreed upon what you are doing is the right thing to do.
Andy Ellis
Yes. So you should publish the here is what we claim we are doing, so that you can sanity check that, but then all of your scores are against the claims.
It is time to play What is Worse?
00:15:51:16
David Spark
Ed, I know you know how to play this game. Andy, you do know how to play the game, whether you like it or not. This comes from Neil Rothenberg who is the CISO over at Rapid. He has submitted a ton of phenomenal What is Worse scenarios. By the way we were talking [UNSURE OF NAME] who has also submitted a bunch of What is Worse scenarios about making a leader board for all the What is Worse scenarios that had gone up. And again, as you know, I always like split decisions. You are a CISO at a company which is a development company. They develop a SaaS solution that they then sell. So, the company is almost entirely Cloud based, only SaaS, slash IAAS. But is that how you pronounce I A A S?
Andy Ellis
I have to go IAAS but whatever you want.
David Spark
IAAS, I do not even know. Okay, here we go, What is Worse? Scenario number one. You have no Cloud security team, none. You rely on Dem Op for any Cloud security task but you have a great application security team. Or the reverse of that, no application security team, you rely on developers for any application security task, but you have a killer Cloud security team. What is worse?
Andy Ellis
This one, I guess I have questions and I always do this to you.
David Spark
I do not have any answers.
Andy Ellis
I guess if I am relying on them for tasks that does not mean I do not have tooling that tells us what tasks to go do. And so, I think in that, I would rather than an honest answer, rather have rather than what is worse. I would rather have that my Cloud security is handled by the developers and that I have an App Sec team because I think I can outsource finding Cloud security problems to vendors more easily than I can outsource the App Sec to vendors. I think the App Secs are so many different things. So what is worse would be my…
David Spark
But you are saying that this is going to be fixed some how?
Andy Ellis
No, buy a tool– no, no, I am not fixing it. But if I am doing App Sec or Cloud Sec, I have tools from CSPM to SENAP. I have got App Sec tools, SaaS, DAST, whatever. So, it is like who is operating those? Are those being operated by developers or being operated by a security team? And if I only get one security team I want the one that is actually going to think about the App Sec because App Sec I think is far trickier than Cloud Sec.
David Spark
So, you think number two, no application security team…
Andy Ellis
Is worse.
David Spark
…you rely on developers for any applications. That is the worst scenario. I throw this to you Ed. Which is worse?
Ed Bellis
I would agree for slightly different reasons. But probably the core is 100%, which is to say App Sec in general is a harder problem to solve. It is more unique to you and to your environment than Cloud security is. That is not to say, yeah, do not beat down my door and start emailing me about how Cloud security is important, this is What is Worse we are playing here.
David Spark
Again it is What is Worse? They both stink. We always have to remind people it is not like it candy and poop.
Andy Ellis
It is a candied poop or pooped candy. Your choice.
David Spark
Pretty much yes.
Ed Bellis
Yes, yes indeed. So, App Sec is more unique to your environment, so, you are going to need somebody that is more dedicated to that in-house, than something like Cloud security, where I would argue that it is the same reason it would take longer I think to wrap up somebody on application security for your applications and your business, than it would take to ramp up somebody who is doing Cloud security for you in an AWS, Google, Microsoft environment.
Please. Enough. No. More.
00:19:26:03
David Spark
Andy, we have discussed this topic of vulnerability management many times before on this show. So, I am going to set it up slightly different than we usually do. Steve Zalewski, who my co-host on Defense in Depth said, “No one is happy with their patch management solution.” Would you agree with that assessment? Why do you believe the constant frustration of what would make them actually happy about how their vulnerabilities are managed?
Andy Ellis
So, I do in general agree. And I think that there is a big challenge here which is many organizations do not actually understand why they are doing patch management. In fact I would actually argue that patch management is the wrong way to think about it. Mostly this is about a maintenance problem. And companies love deferring maintenance. They are like, oh look we can just take this Log4j thing and throw it here and it does our logging and we do not ever have to worry about it again. And I think open source enables this. I do not want to say it is to blame for it, but it enables it. Because you like I do not have to do any work. I have found the code. I have integrated it once and I walked away. So, because they do not think about it as a maintenance problem, that we just have to routinely invest in maintenance. And every so often I have got to patch out of cycle because I have to do something for a zero day. That should be the way people approach it. Instead they approach all patch management as an incident. And you cannot operate at incident tempo doing basic maintenance. It would be like saying what if you only filled the gas tank on your car whenever it ran out of gas. That would be an awful way, and anybody who has an electric vehicle fine, plug it in whenever it ran out of charge. This is not how you operate a vehicle. Every so often you plug it in, you give it basic maintenance, you fill the windshield wiper fluid. You do not wait for these things to fail and the car to be broken down on the side of the road. But if you do you are going to not really like your process. And that is how most people deal with patch management.
David Spark
And I would assume you would argue that your customers do like their patch management? They are not dissatisfied.
Ed Bellis
So, actually I am not in disagreement with Steve on this one. Caveat, Kenna does not actually do patch management. In fact, if we looked at the data, and if people are expecting patch management to effectively mean that they are going to patch all their vulnerabilities, then nobody is happy with their patch management solution because nobody is patching all of their vulnerabilities. I would also say it depends, right, so, for patch management we see people are really good where they have automated patch management. The common example, everybody is using Microsoft SCCM or something like that. And they do a good job at patching their Microsoft vulnerabilities after Patch Tuesday. It is consistent. There is a process around it. But as you get further away from the OS, the more difficult it becomes. And when you expect somebody to run a patch management system to say, upgrade JAVA, it is not going to happen. There is a lot more complexity to it. There is regression testing that has you recompile apps. There is all kinds of things that have to happen that make it much, much harder to do. It is not just push a button and you are patched. In fact even when we look at the mean time to remediate for these vulnerabilities, the long pole in the tent is not actually applying the patch, it is all of the process that they go through to get to pushing that button to push the patch out. So, if people are expecting a patch management solution means that I am suddenly patching all of my issues, then no-one is really going to be happy with that.
David Spark
So, speaking to what Kenna Security does, and my apologies for confusing patch management with vulnerability management here, the way you have made your mark is to say that Kenna Security is all about the risk that is needed to address the vulnerability. And one of the things that you have said previously on our shows is, you can ignore 60% of your vulnerabilities.
Ed Bellis
Yes. So, that is kind of the area that we focus in and on its prioritization and understanding the risk of particular vulnerabilities, particular groups of assets, all of these things. It is all asset based risk model. And really our position is, is you do not have to patch everything is the core message. But if you want to patch, here is the prescribed order of things that you should do them in, so that you are reducing the risk the most with the least amount of effort. And by all means we would love for you to get down to zero. But we also recognize the reality that that is not going to happen.
David Spark
It is kind of like a diminishing rate of return here.
Ed Bellis
There absolutely is. At some point you get to a point where you could probably do a better job with your security program, applying those resources to somewhere else, than patching that really low risk [UNSURE OF WORD]. There is probably some other strategic security initiative that you have going on that you could apply those resources to, and get a lot more bang for it.
David Spark
And is that understood when someone is using your platform?
Ed Bellis
Absolutely. In fact it is kind of built in to what we have this thing called Top Fixes. Which is basically so, whenever you are looking at any particular group of assets, we are going to give you that prescribed bang for your buck list, and say if you are going to do something, do these five things or whatever. And here is what your risk is now and here is what it will be at the end of it. We will tie that in to ticketing.
David Spark
And tying us back to Ross Young’s chart that he made earlier. Because his whole thing was to try to show that we are being more sort of risk adverse and that risk is being controlled and managed and gone down. How does that tie in to telling a CISO, things are improving risk wise here?
Ed Bellis
That is exactly what you want. That is the story that you want to tell. Here was my risk last quarter. Here is what we look like now. Here is where we are going and here is the resources that it is going to take to get there. Do we all agree that it is worth getting there with these amount of resources? And that’s what you want to measure. It is not about aging vulnerabilities. It is not about defect density. Because in reality when we look at it on average any given company at any given size, whether it is an SMB up to the Fortune 10, on average they are fixing about 15% of their vulnerabilities. And the top performers are probably less than 30%. So, if you are measuring defect density the answer is it is always going to get worse.
David Spark
So no-one is going to be happy about that. Well that is a really, really good point. Thank you.
Close your eyes and visualize the perfect engagement.
00:26:08:20
David Spark
How often should you be conducting vulnerability scans? This question was posed on Hacker News and they boiled down the decision on five different times slash factors. And they are change: hygiene; compliance; resources, being your own resources, and emerging threat. I will start with you Andy. Are these good vectors to consider? And how much do people actually consider all of them? Or do they just have a regular schedule based on time? What is the advantage of being more methodical about the timing of your vulnerability scans?
Andy Ellis
So, I think you should separate out the idea of scanning from the pipeline that follows scanning. And I think what happened here is it feels like they tried to combine those two. Scanning is the thing you should do continuously. You should build the system that has a capacity to engage scans rapidly. And then you can do them at a low rate for whatever you want. Let’s say you are doing weekly scanning to just sort of touch every system that you have. And build up a baseline. Because one thing you are looking for is deviations. Hey this machine works fine and now it is not. You can then run it more rapidly. If you are like new zero day vulnerability for which we could scan, sometimes you can. But let us drop into the scanner and on a zero day if you are like oh yes, we are able to do a scan of everything on our environment within four hours. We normally take a 168 hours to do it, because we want to be low and slow, but we will hop up to fast. Great, we can do that. And it might be that from a compliance perspective they only care about doing the scan once a quarter. So, fine, output your once a quarter scan, the once a week one, and there you are just handing over that from a compliance perspective. That is my take on it. You should always be able to look at the state of your environment. Not much more than a week or two in the past, that would be ideal. I know for a lot of people they are not doing that. And maybe it is a high level scan that is happening regularly. Then you are doing deeper scans at a lower frequency. A lot is just going to depend on what your capabilities are.
David Spark
By the way what you said, Andy, regarding pipeline, that is where the resources situation came in. It is like do I got the resources to handle this? How much should I flood this?
Andy Ellis
And how am I going to consolidate this down to hand it to an engineering team to go fix something? Are the firewalls configured correctly on all of these systems? Maybe that is what you are just doing in a continuous fashion, is checking for firewall rules. But then you are also doing the, hey, let us just verify the version of SSH. We do not need to scan it to see if I can break in on a regular basis but I just wanted to do a version check.
David Spark
Throwing this one to you Ed now. It is like what Andy said, it is more than just scans, it is the whole pipeline here. What is your take on these different ways? And is there value to be thinking about it this methodically? Or just do this based on time? It seems like it might be an unnecessary headache to be thinking about and dealing with it this much. Yes or no?
Ed Bellis
I would say it is not so much about dealing with it so much as it is it felt like going through the articles is a little bit more of a thought exercise than is necessary. I agree with Andy’s point. I think you have got to look at scanning or assessment as the visibility portion. I need visibility into it, now I have got this other pipeline of resources for fixing the issues we decide need to be fixed. And whether I fix those daily, weekly, monthly, quarterly, whatever it is, I will make sure that I have a process that connects those to, so, when it is time for the fixing to begin, I have got this prioritized list of, alright, here’s what we are going to go after and here is what it is going to take to after it. So, I would separate those two. I think that there was quite a bit that went into that article. I am not sure it was all that, in some cases, necessary.
Andy Ellis
It feels like the author might have been paid by the word.
Ed Bellis
Well I will say that it felt like the author was actually pitching a particular product.
David Spark
But I think what you said was kind of right on the mark. This is more of a thought exercise than anything else. The reason we scan is for these reasons, for compliance reasons. For the issues of whether we have the resources. For the when is the last time you did it kind of a thing? So, I mean I think it was good just sort of, like, are you doing this?
Andy Ellis
There should have been this sort of consumers of your scanning. You are doing scanning, why? Oh you are doing it for compliance, you are doing it for vulnerability detection, you are doing it for detecting software pipeline defects. Here are the reasons you do it, so “design yours thinking about those reasons,” might have been almost a better way to phrase it.
Ed Bellis
That is true and I would argue though that at least most organizations that we see, they doing it for a lot of those reasons, if not all of those reasons. And the consumers are different depending on what it is that they are doing. It might be for my IT Ops team. It might be for my audit team. It might be for whomever. And I will say that we have seen, year over year, people have definitely upped the frequency, to the point where we have some that are running agents. Or they are doing, I would not say continuous scanning, but it is at least hourly reporting back as to what it is seeing. And then we see, probably less so than we used to, but there are still organizations out there that I am sure that are doing a quarterly PCI scan or something like that.
Closing
David Spark
Well that brings us to the very end of our show. And I want to thank my co-host, Andy Ellis, Wild Ventures. And also our sponsored guest, Ed Bellis, CTO and co-founder over at Kenna Security, which is part of Cisco right now. Thank you so much. Now I am going to let you have the very last word and I have to thank your company, Kenna Security and Cisco for sponsoring this episode of the podcast. But first Andy, any last thoughts?
Andy Ellis
Well,I have got to say there is so many vulnerabilities out there that people both need to think about prioritizing the ones that matter. But I think they also really need to think about how do you just manage your system? Take a step back and realize that the fact that you have to pick which ones to prioritize probably already means you failed somewhere earlier on in your life cycle. Don’t not fix the ones that matter. But also try to deal with the life cycle a little bit earlier if you can.
David Spark
Good point. And Ed, as we always ask our guests, are you hiring? I am pretty sure Kenna is hiring and Cisco is hiring for that matter. Please let us know. And lastly any pitch for Kenna Security as well.
Ed Bellis
We are 100% hiring. Please, please, please, come visit our job board. It still hangs off of Kenna Security dot com, I think, at the time of airing here. But also at the time of airing we will have launched volume eight of our prioritizations prediction joint research reports, with the Scientia Institute. Please check that out. That also hangs off of Kenna Security dot com.
David Spark
Awesome, well thank you very, very much Ed. Thank you Andy. Thank you Kenna Security. And thank you our audience as always. We love your contributions. Send us more What is Worse scenarios and other good stuff, good questions you may have. Pitches you want us to critique. Or any thing that is on your mind that you would love to get some security leaders take on, we would love to hear it. And do all that at CISO Series dot com or just ping me directly at David @ CISO Series dot com. We appreciate you participating and listening to the CISO Security Vendor relationship podcast.
Voiceover
That wraps up another episode. If you haven’t subscribed to the podcast, please do. If you’re already a subscriber, write a review. This show thrives on your input. Head over to cisoseries.com, and you’ll see plenty of ways to participate, including recording a question or comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at david@cisoseries.com. Thank you for listening to the “CISO/Security Vendor Relationship Podcast.”