Patching Best Practices 2019
May 08, 2019
Chris Goettl | Director, Product Management, Security | Ivanti
Sara Otremba | Product Manager | Ivanti
Patching is a hot topic in security breach after security breach. Patch management is likely the most well established security control out there, so why do so many companies struggle to achieve a good patch management strategy?
Join us as we discuss the pitfalls of patching, the complications that still plague us, and best practices to help you fine tune your process—with a dash of just plain common sense thrown in. We will also look at ways Ivanti can help you get a handle on patch management using our latest security innovation, Patch Intelligence.
Hello, everyone, my name is Chris Goettl. I'm the director of Product Management for Ivanti Security product lines. And today we wanted to do a, basically a run of our, we do this every year at our corporate show interchange, where we have a best practices session around patch management. And it focuses on a variety of different challenges. You know, what's trending, what are new issues that are coming up, challenges that people are running into, and recommendations on how to overcome some of those challenges. So, we're gonna cover a lot of things today. It is meant to be less product and more kind of industry best practice around this. So, even if you're not using one of Ivanti's patching technologies, you should still find some very good information to take away here. If you do have any questions, you can go ahead and submit those through the Q&A section and throughout the presentation, I'll see if I can answer things in line or we'll have some time at the end where I can answer some additional questions as well.
So, like I said, we just did the best practices session you're about to go through at our corporate events in Nashville last week, and had a lot of people attend that session, and, you know, get a lot of good feedback from, you know, challenges that they're facing as well. And we wanted to share those with you guys. So, let me start going through here. First off, we're gonna start with some trends and pitfalls, you know, challenges that people are running into. And this is kind of, you know, some of these are have been happening for some time. Others are, you know, some more fairly new developments. But the goal here is to give you kind of a good mindset, and then we'll start going through more of the best practices here in a little bit.
So, one thing that we've been seeing is the trend in vulnerabilities being identified and resolved every year is continuing to increase. If you go back as far as 2011, we were up above around 4,000, you know, reaching towards even 4,500 to 5,000 in 2010. If you, you know, keep up with sites like CVE details, these accounts are filtering out any, you know, CVEs that were still in question or weren't confirmed. So, this is the total number of CVEs that were opened, identified and, you know, resolved by vendors in that year. And you can see here that we had a pretty good spike in 2014. There were a lot of a...that was the year where they started to include more of like the phone operating systems as well. In 2017 year, we had a pretty large spike as well where a bunch of additional vendors starting to submit vulnerabilities. And in 2018, we still continue to see an increase in the total number of vulnerabilities.
One thing to keep in mind is, you know, this doesn't mean necessarily that we're in a less secure world today than we were previously. Just a matter of, you know, now things are more well known. Now there's more devices and with each of those devices, yes, there are vulnerabilities in each one of those, there's, you know, more software than ever coming into our networks. And each piece of software introduces more vulnerabilities as well. But, you know, inherently, every piece of software, every device on our networks is a security concern whether that vendor is diligent or not. So, one thing we know with this trend is we are seeing more and more vendors maturing their vulnerability management process within their organization. Being able to identify, respond to, and resolve security vulnerabilities on a regular basis in their products. So, that's the silver lining with the trend that we're seeing here is it is showing you a lot more of that maturing of the industry. You know, the concern has always been there, things are always insecure. But now we're seeing the maturity of the industry catch up and start to resolve more of those vulnerabilities and make us more aware of those vulnerabilities.
See, if you are having some problems with the audio, I do see there's a couple of people, this typically happens. If you're trying to use the computer audio, it is best to switch over to the dial and if that's becoming a problem, so you might have to switch over to the dial-in. Okay, so, continuing with that vulnerability trend, over the last couple of years, we've seen a couple of interesting things happening. And this is one of those where, you know, as new products are introduced to your environment, you know, they are, again, each one of those has potential for security risks.
So, one thing that, you know, came up in 2017 is this product called ImageMagick. Other products did the same thing, but ImageMagick was one of those that came out of nowhere, and really jumped very quickly up to being one of the largest or highest vulnerability counts for an application that year. So, ImageMagick, you know, if you look into this piece of software, it's a pretty basic, you know, tool. You can do bulk edit, so GIF images, you can edit and process, changing multiple images in large batches. It's not a very complicated product or anything like that. But, what we saw though, is in 2017, this product went from maybe resolving a handful of vulnerabilities each year in, you know, all the way back to like, you know, pre-2010 to suddenly jumping up to 357 CVEs resolved in 2017, a pretty considerable lead.
It wasn't a matter of suddenly ImageMagick had a whole bunch of vulnerabilities where they didn't before. It was a matter of ImageMagick started to get attention, whether it was internally, you know, of their own devising or security researchers driving attention towards them for different reasons. This is a trend that we've been seeing with a number of different vendors where security researchers, their own teams, they mature their management of vulnerabilities in their product. And now we understand how many vulnerabilities that they have. So, one would hope that over the next few years, that will taper down and become less and less overall as they clean up vulnerabilities in their product. But at least now they're making themselves known. They're making sure that we're aware of the risks of the products, the versions that are installed in our environment.
Another trend that's been happening a little bit over time is software alternatives. If you, you know, over the years, we've seen a number of, especially in the PDF space and browsers, you know, the software alternatives, you know, come up because people desire a different experience. They might desire less costs, they might desire, you know, a different way of approaching a problem. But the bottom line is each of those applications are still, you know, you're not gonna get away from software vulnerabilities there.
So, another trend that we've seen over the last few years is, if you are looking at alternative PDF products, Adobe Reader and the Adobe products around PDF creation and modification and viewing have always been one of the more targeted applications out there. And it's because of the nature of PDFs. PDFs are everywhere. People will have Adobe Reader on a lot of system structure environment. It's a piece of low-hanging fruit that threat actors know will be in environments that they can get to. So, when Foxit reader started to become more and more popular, one thing that I did hear, not a lot, but I heard a little bit, you know, people who were constantly concerned with Adobe vulnerabilities and Zero Days and other concerns there, they were trying to escape from the security issues around Adobe Reader and try to move towards a more secure application. Well, Foxit as these guys were coming out, they've been maturing their vulnerability processes over the last couple of years as well.
And now in 2018, you see that, you know, they had 187 CVEs resolved in Foxit reader for the year. As more and more people devote attention to Foxit, and as Foxit releases more and more features in their product, you can assume that the number of vulnerabilities will continue to increase or at least stay up at a higher level here. So, Foxit being one of the biggest alternative PDF viewers and creation tools compared to the Adobe products is not less of a security risk. If you're going there because of cost differences, great. If you're going there because it provided you an experience or a capability that Adobe did not, great. But if you're trying to go over to this alternative based on security, that's a misnomer. That's definitely not a behavior that you're gonna find.
So, one thing to keep in mind as you look at this, just because an application, you're using in your environment doesn't report any security vulnerabilities, that does not mean that that software is secure. You need to assume that all software is inherently vulnerable. You should be updating all software in your environment as consistently as possible to close out vulnerabilities known or unknown. And, you know, again, those lesser known products or those alternative products, you know, that they are not more secure because they don't have vulnerabilities reported. Just a matter of their practices may not be mature enough yet to make those issues visible.
All right. One other challenge that, you know, it's been happening more and more is, you know, companies are starting to get a feel for the fact that what they don't know can hurt them. Last year, we had a number of Ivanti customers reach out to us because a new CISO came on board and they wanted to have a conversation around their security concerns. So, naturally, I got pulled into many of those conversations. And one thing that was interesting is in eight conversations, the number one issue for all of those new CISO was the same. It was very much security-related, but it was very much around knowing what's in their environment. They were afraid of those systems that they didn't know about.
If you look at this example here, you guys will be able to get this presentation later. But this was a casino, an article about a casino that got hacked a couple of years ago now. And the device that the attackers were able to get in and start their attack from was actually a device hooked up to a fish tank. So that fish tank was, you know, it might have been in the casino lobby, you know, behind the desk where people were able to see these beautiful fish swimming around. The device hooked up to it was set up to control tank conditions and be the fish on a regular basis and monitor, you know, the overall experience of that fish tank to make sure that it was a good experience. Well, that device, if not properly managed, could easily become that foothold that an attacker could use to gain access to an environment. And in this case, that was the foothold that the attacker used.
If you've also read articles about breaches, so if you've ever read a breach article about a retailer that was compromised, and in the article, they talked about how that company passed their most recent PCI audit. Well, that's another challenge that a lot of companies face is, you know, if you've got a regulatory requirement for a certain part of your environment. And that's where you focus all of your attention on security and making sure you can pass that audit. You do still have to worry about the rest of your environment. Majority of those cases, it's systems outside of the IT organizations control or systems that they weren't managing to the same level of control that became compromised. And from there, attackers don't, you know, they don't need to use the same tactics to get into the PCI environment that they used to get on to a non-compliant system.
From that non-compliant system, they're gonna be able to gain access to credentials and tools that you use on a regular basis. And the way that they get into that more compliant environment is using your own credentials against you and system tools that your IT organization is using to manage your room environment. So, that compliant environment becomes exposed by the non-compliant environment not meeting the same standards.
So that's another challenge that a lot of companies face. And in fact, it was interesting reading Gartner's 2019 predictions for asset management. Amongst other predictions they had in there, one very clear one was a prediction that by 2023, 50% of asset management initiatives in organizations are gonna be spearheaded by the CISO and led by the security team. So a process that most people consider just an operational and a cost savings initiative is becoming more and more of a hot topic for security because if you don't know about those devices, that could be the systems that leave you exposed and gain that foothold for the attacker.
Another trend that we've been seeing is the embrace of DevOps. There's a lot more applications that are built around development binaries and around platforms that make it so that organizations can develop and deliver applications faster. And with that, though, comes additional responsibilities. So, you know, you've got the...if you go back to the Equifax breach, this is where attackers came in, they started to scan the web for vulnerable servers, they found a vulnerability within Equifax that allowed them to gain access.
From there, they exposed and moved around the environment. They got login credentials, they gained access to the database where they were getting, you know, the essential data that they were after. And, you know, in a lot of the articles that we read up on about that, you know, one thing became very clear, there was this component called Struts in the Apache web platform that was exposed. And it was because of, you know, somebody not patching that that this access to this data became possible. Well, at the end of the day, Struts is a component that, you know, you can't just go and patch. You know, similar to that, you've got other components like instead of .Net Framework, now there's a component called .Net Core that a development team can bake in the .Net components that they want to use directly into their applications so that you don't have a prerequisite of .Net Framework along with your application to install. Chakra Core, Java 11, we'll talk about that a little bit more in a second.
But other platforms and development environments all have the same kind of a new challenge that's being introduced where development teams will take those binaries, integrate them directly into the application. And with that, now, the responsibility of keeping that up to date to resolve security vulnerabilities falls to the DevOps team instead of the operations team. Because there's no longer an installable patch or update to be applied.
So, at interchange last week, we were down in Nashville and we had hundreds of customers out there with us. I was at a roundtable discussion over breakfast one morning, and I had a handful of fairly large customers there and we were discussing some trends, especially this trend here. And we started talking about Java 11. So, for those of you who are unfamiliar with this yet, Oracle, end of life, Java 8 in January, that was the last publicly available, or commercially available update for Java 8. So, in April, when they had their next quarterly update, there was no commercial update for Java 8 JRE. So, the runtime is now, you know, if you don't have an extended support contract with Oracle, you can't...you're not legally able to update the Java 8 runtime. So that presents a challenge for a lot of companies. So, naturally, we're obviously all moving forward to using Java 11. But there's another new change that's been introduced here. There's no longer a JRE. There's only the JDK now. So the development environment is the only installable component that can be updated when Oracle does a release each month or each quarter.
So, in the next quarterly cycle here, when Oracle releases an update, it's gonna be for Java 11's JDK environment. That's the development environment for the...your own development teams to be able to update. With that though, they need to actually produce a new build of your custom applications. And when they do that new build, any of the binaries that they need to use for that, so what would have made up the Java Runtime Environment, what would have been installed at the endpoint before, that now gets built directly into the application at the time they build the app, and then the development team has to redistribute that applications out to all of your users. So, this is a very big paradigm shift for a lot of companies and it's catching many of them unawares. Actually, I expect that in, you know, our next Patch Tuesday webinar next week, that we're doing internally here, I'm expecting a number of customers to ask the question of where's the Java 11 JRE? Why didn't we see that last month? And the answer to that is gonna be what I'm telling you guys here, which is it no longer exists?
So, you need to have discussions with your internal teams. If you're embracing DevOps, if you're building custom applications, these conversations have to be had. You got to figure out what types of development platforms are being used. Are the...are you utilizing if you're building .Net applications? Are you using the framework and that's installed alongside the application? In which case, yes, there's a patch every time when releases and from an operational standpoint, you can update it. Or is it more like Java now where the development team has to take on responsibility for that, and that JRE no longer exists? So, now, your development team needs to get on that vulnerability management cycle with your security and your operations teams. And you've got to have good clarity around that and a good process in place to make sure that you're resolving vulnerabilities in a reasonable time frame.
All right, moving on to another challenge that a lot of companies have been facing, which is prioritization. There are a ton of updates out there. It's very hard to figure out, you know, what do you need to update? What should you focus on first? You know, and so, traditionally, a lot of companies started with just vendor severity, oh, if it's a critical update, we're gonna push it out. That started to kind of fall on its face. You can see a couple of examples here. In 2018, we had a few really good examples here. This one here, CVE-2018-8589. This update was only rated as important. So, if you were doing deployments based on severity only, and you were saying only critical updates go out there, you were leaving both this vulnerability which was a Zero Day that was exploited before the update was made available in November.
And also, if you remember this nasty little thing called double killed, this critical vulnerability actually it was a pair of them that allowed an attacker to gain access to and elevate privileges on a box. And again, two vulnerabilities being exploited in the wild before an update was available. We had definite Zero Day confirmations of both of these, they were only rated as important.So, Severity alone can't be your, your metric for deploying that.
Another thing that you'll notice is the CVSS scores for each of these vulnerabilities. All of these were being exploited. There were two other vulnerabilities here on the SAP platform that were being exploited as well. And, you know, none of these are above an 8.0 on the CVSS scoring, but all of them were being exploited in the wild. So, even CVSS score alone can't be a 100% reliable tool for prioritization.
So, as you go through this, make sure that you've got more robust mechanisms for identifying what needs to be updated. You know, one thing that we do at Ivanti is we have a regular Patch Tuesday webinar every month. So, next week as Microsoft rolls out updates. The following day Wednesday, next week, we're gonna have a webinar where we're gonna talk about what came out if there were any known Zero Days or public disclosures which are more likely to be exploited. We will talk about and prioritize those updates higher because of those reasons. So, those are some of the things that we look for some of the indicators that you can also look forward to identify what you should focus on first. And there's, you know, depending on your vulnerability management platform, if your security team is prioritizing in giving you that information, talk to them about how they're prioritizing that and see what metrics they're using to do that. And make sure that you've got good alignment on what should be being prioritized.
Vendor release, frequency, and cadence, this is another one that, you know, as we talk about vulnerabilities that you know, are becoming exposed in your environment. You've got vendors like Microsoft and Adobe, where they standardize on a regular release cadence. They're gonna be releasing around Patch Tuesday, that second Tuesday of the month, pretty consistently. They'll do, you know, Adobe is known to do some Zero Days, you know, some updates as needed. But many of the other updates are gonna fall on that second Tuesday of the month. Oracle, although it's doesn't fall in line with the Patch Tuesday that Microsoft at Adobe have standardized on, does have a quarterly cadence that falls into a fairly predictable pattern. Most other vendors though, if they've embraced continuous delivery, you know, especially the browsers, Google and Mozilla are going to release their browsers roughly around certain time frames. But for the most part, when it's ready to go, and it's matured, and it's, you know, providing value, they're gonna release it. Other vendors, it'll release all over the board.
So, I've brought together a few different points from this year so far, just to give you an idea of outside of those Patch Tuesday windows. So, I didn't include, you know, week three of this year, which was a Patch Tuesday or week seven, which was another Patch Tuesday. But weeks four, five, six, eight, nine, and ten, these are all updates that came out in those timeframes that included security vulnerabilities. You see Apple iCloud, and iTunes, there were 14 CVE with three of which were at a CVSS scoring of a 9.8 meaning they were pretty easy to exploit and gave an attacker, you know, fairly full privileges to be able to exploit that. Chrome, 58 CVEs were resolved in this update on the fifth week of this year. Firefox resolved another seven that same week. Week six, PrivExchange, for those of you who remember this advisory coming out, they patched it, you know, later on after that, but this PrivExchange vulnerability was, it was threatening enough that they put out an advisory, they gave mitigation steps.
So, keeping track of and understanding this information as it comes out is fairly important. If you...depending on how you build your, you know, patching process out, this is going to help you make the case for certain systems potentially being on a more frequent basis. So, you know, understanding that release cadence and what happens between those Patch Tuesday windows is very important because a lot of the vulnerabilities are being resolved. And attackers basically get the chance to start reverse engineering and trying to take advantage of those. And they're hoping that you're not gonna get to them faster than they can exploit them.
All right, so people, you know, there's still the challenge of people being our weakest link. If you look at majority of security incidents, 90% of them, of breaches are still going to involve some level of phishing or user targeted attack at the onset of that, you know, that's the way that they're going to get into that environment. Forty-nine percent of malware is still installed via email, by people clicking on it and that malware getting installed on systems in your environment. At any given time, if you're using like Wombat or PhishMe or you know, some internal tooling like that statistics from those vendors still show that any phishing campaigns that people are running internally still are going to get to about 4% of the recipients. They're gonna open and click on that phishing campaign that was put out.
And you know, even the most security-minded of us could be targeted and be exposed at some point. So, I've been in the industry for you know, a while now, I'll be actually October this year will be 15 years with this company. And, you know, one thing that I have prided myself on is, I have always been able to identify and avoid getting caught up by any of our internal phishing campaigns that our security team is wrong. They finally got me, literally, only three weeks ago. It was the end of the quarter, you know, so part of my responsibilities as managing our security product lines is also, you know, keeping an eye on our security business. So, end of quarter came around, and they doctored up, you know, an internal announcement that looked exactly like internal announcements that we would expect to see. And with that, they basically tailored it to an event that they knew what was happening, it was a end of quarter and you know, all business, you know, owners are aware of and concerned about how their closing business went for the end of the quarter. And they addressed this in a way where I was immediately caught up in, "Oh, shoot." You know, this just went out to a whole bunch of people. I need to know what type of information they're about to show everybody who's now gonna be asking me direct questions.
So, I didn't look for those telltale signs. I clicked on and boom, there it was, that phishing. You've been phished. Here's where you fail to notice those telltale signs. So, even me, somebody who has taken a lot of time and effort to help train and educate people on the risks of phishing attempts like this, I was caught unawares by a phishing campaign as well. And you know, if there's somebody who is focused and dedicated enough to exploiting you, they're going to spend the time and figure out what are critical events? What are moments that they're looking for? How can they create and provide an experience that's going to take the key people that they're looking for unawares, and be able to phish their way into that environment? So, I tell that story because it puts things in perspective for people. Any of us can be hit at any time because we get caught up in and blinders on to the telltale signs if that phish is doctored up just the right way. So, weakest link is always the end user and all it takes is one person and that attacker could be letting the door with very little effort.
All right, so, those are some of the trends that we've been seeing. So, as we go through this, you're gonna see some of those now turn into more of a direct kind of best practice. And a few more of these that traditionally have been around for a while, we're just kind of refining and providing you some additional tips around them. So, here's the best practices session. Part of it, that for...one of the first one we wanna go through is we message a lot to a framework called the critical security controls framework. So, the Center for Internet Security puts this framework together. It's made up of feedback from industry experts, from vendors, from practitioners in the space. It's based on real attack scenarios. And its purpose is to go beyond the limitations of vertical-based regulatory requirements.
So, we talked about PCI before and oh, yeah, my PCI environment just passed this audit, but yet the company got breached. You know, a few months later somebody was able to get in. How does that happen? Well, the CIS framework is focused on trying to solve those exact same problems. This is not an environment in your environment that should be compliant with these requirements. This is the whole of your environment. So, this is looking beyond verticals, beyond regulatory frameworks. This is getting down to security best practices, basic security hygiene, operational efficiency driving towards real attack scenarios and how to mitigate them. The top of that list is around inventory and control of hardware assets. And number two on the list is inventory and control of software assets.
So, ask yourself, what is your best source of truth? If you were to sit down with your organization, you know, cross-functional team from your organization today and say, "If we were to look at and identify what is our best source of truth for the total number of systems that we manage today, what would that source of truth be?" And we've had this discussion with a lot of customers and the answer is there is no one source of truth that has it all. We've yet to find somebody who really does have that one place where everything is pulled together. In fact, we've talked to a lot of customers who are saying, "Yeah, we actually had to pull together a project. And there's teams of people from all different parts of the organization. And we're pulling data from our systems management platform, and from active directory and from the AV solution and from our assets solution and manual spreadsheets."
And this team is correlating that information to try to find out what we all actually have to manage. And they're still finding, on average, you know, 20% to 30% that they may be off by for any one source within their organization. So, the only way to get to a true source of truth is to bring multiple sources together and ensure that you've got additional discovery capabilities that are going out and actively identifying systems, whether it's as they're being purchased using B2B connectors and understanding everything that's purchased and brought in, being able to understand other devices that come on through shadow IT issues and other ways, BYOB, bringing other devices in that are outside of the normal purchase process. Biggest issue there is, if you don't know about it, you can't secure it, and if you can't secure it, that might be your phish tank.
So, one thing that we're working on right now, we actually showcase this quite a bit last week. Our Ivanti Cloud Platform that we're building out right now, for those of you who are Ivanti customers, look at this feature called Device Reconciliation. This is purpose-built to help you solve this problem. Take multiple sources of input and be able to reconcile those and boil it down to here's the total set of systems, the superset of systems that we believe we're managing throughout our environment. And still, that may get you closer to that 100%. But your environments are always changing. So, make sure that you're constantly refreshing your assets system, that you're constantly pulling in more sources of data, and that you're reconciling that. So, we built an experience around this, to pull together many data sources and to be able to do that reconciliation for you. Definitely something to look for if you don't already have an initiative going to do that type of reconciliation because this is where it starts. This is the only way to make sure that you're identifying all the assets that you have to secure.
All right, another challenge that a lot of companies have been having that, you know, one of the best practices going forward is how do you get past this gap, bridging the gap between security and operations. So, control number three in that CIS framework is continuous vulnerability management. So, on your security team side, this is your Rapid7's and qualities and tenable and your vulnerability assessment solutions that are in the environment. And on the operation side, this is your patch management solution. So, these two solutions look at the world differently. They're assessing for different things. But at the end of the day, the goal is the same. We wanna resolve vulnerabilities.
So, how do we more quickly get from assessment to remediation? We talked to a lot of customers about this challenge as well. And what we found is the majority of organizations on any given, you know, month will get a report from their security team. And in that report, there will be a ton of vulnerabilities. So we've got those two solutions coming together. From the vulnerability side, I get a report of tens of thousands or even hundreds of thousands of detected vulnerabilities each month. The process of going through and duplicating that list because...you know, let me give you an example. If I've got 5,000 systems in my environment, and the majority of those are running Adobe Reader, in December, Adobe Reader released an update that resolved over 80 vulnerabilities, just one update.
So, if let's say 3,000 of my systems had Adobe Reader on it, that's 3,000 times 80-plus vulnerabilities all from that one application update needs to be deployed. We've already got tens of thousands of vulnerabilities just from that one update. Between then and February, there was a Zero Day release for Adobe. And there was also another release in February that came out with another 60-plus vulnerabilities. If I had a handful of systems that were missing that December update, that means that 80-plus that Zero Day plus those additional 60-some vulnerabilities were all missing on that one system. If I've got many systems missing that, you can see how this snowballs very quickly. So, a lot of what the operations team ends up having to do is de-duplicate that list. Okay, you gave me a list of 400,000 line items. Well, in there, there's actually only 1,000 unique CVEs that I actually have to go and figure out.
Okay, well, if we go back to that Adobe example, I don't need to worry about 140 vulnerabilities, I just need to worry about what update do I need to put in place to take care of all of those updates. So, now we get into things like supersedes, and, you know, mapping to the exact software updates that are going to resolve those vulnerabilities. So, a lot of this takes research time. And on average, we talked to many of our customers and they were burning a day per month or a day per vulnerability scan to be able to do that. At Ivanti, we do vulnerability scans twice monthly. So that means our operations team was paying this cost twice a month doing that research and finding out what needed to be done and then trying to, you know, figure out where and how they can take action to resolve those. We're able to do this with a feature within our patch solutions. And the majority of that de-duplication and mapping exercise can be done in less than a minute.
So, this is a new feature within our patching solutions called CVE Import, and all it does is it's a data exercise. We've got the mapping already laid out. We know exactly how to do this. We've been doing it for years. All we've done now is made it so that you can do this extremely easily. With our patch for SCCM, our Security Controls or patch for Windows product for those of you on the old day vignette and our patch for endpoint manager solutions, you can take that vulnerability report. You can import it. It can be in any format you want. It can be any size that you want. All it needs is those vulnerability IDs, those CVEs, and with that, we will map those vulnerabilities directly to the software updates and present you a list and say," Here, this is what you need to publish, approve, or, you know, start testing to resolve the bulk of that vulnerability report." So, I've now taken five to eight hours and boiled it down to a matter of a few minutes to resolve the majority of those vulnerabilities.
So, a very powerful new feature that are, you know, for those of you who are on any of these products, the patch for SCCM and security controls versions are already out and available with that feature. The endpoint manager version that will include this is the 2019.1 release, for those of you not on those features or those products. You know, look at how you're doing this process there and figure out how can you bridge that gap easier? Because this is burning a day every month on average, in your environments.
So, we talked a little bit about prioritization, one thing that you need is more sources of prioritization. So, I talked a little bit about our Ivanti's Patch Tuesday webinar, every Patch Tuesday, we come out and give you an assessment like a summary level of here's what came out. And then we talk about things like how many Zero Days were there. We give you a breakdown of here's the updates that came out, here's the Ivanti priority, here's the vendor severity, here's the threat risk. Here's additional details about why we bump this up to a priority one when the vendor says, "Oh, it's only important." Well, in this case, this exchange vulnerability in February included publicly disclosed vulnerabilities, that privilege exchange vulnerability we talked about that made big news. And basically, talked about the fact that this is a vulnerability you should be concerned about because public information has been distributed to a very wide audience, the risk of this being exploited increases. So, your prioritization of this should increase in time.
Same thing here with the Internet Explorer update that month, we had an exploit in the wild. Here's the CVE, other indicators that we look at are user-targeted vulnerabilities. If that update is resolving those, those are again vulnerabilities that can be used in phishing exploits, in web-targeted attacks, drive-by downloads, things like that, side-loaded content that can be loaded with malware. These are all indicating what concerns you should have about these updates and giving you more of that prioritization so that you can make sense of this and be able to drive further towards that. And we're continuing to expand that prioritization, you know, and be able to focus in more on these details. We've got this new capability that we're building out right now. Again, back in our Avanti cloud platform, which is launched now, we've got, I believe our count of active customers up there now is nearing 1,000 companies that are utilizing our advantage cloud platform and features that are being developed up there. There's a new capability up there called patch intelligence.
So, think of these types of prioritization capabilities. But being able to map that to the information from your environment, being able to see that side by side, we're also building out additional capabilities to understand the reliability of updates, to give you access to see, you know, not only if you're deploying patches to your own environment to a test group, how many test systems can you feel? Well, the answer to that question is never enough. You're always dealing with the law of small numbers. So, this gives you the ability to see not only your test systems, and how many of those have been deployed and how many issues people have run into, known issues that have been reported, rollbacks that might have occurred, but also see an anonymous pool of other systems globally, that will be collecting in here as well.
So, not only can I see my Windows 10 systems that I got tested this month, but I can also see the thousands of other Windows 10 systems that have also been tested across our pool of customers. From that, you can get better risk and reliability information and make decisions faster. Staying informed is also very important. One thing that we do with all of our Ivanti Patch Solutions is we have content notifications that you can sign up for. So, we're releasing content at least twice weekly for all of our patching solutions at Ivanti. And with those, you'll be notified as each release comes out. You'll see what updates were released, details about that, and be able to keep informed and up to date of how frequently updates are being made available to you. With that, you can take actions quicker on the things that are more concerning.
Talking about that, you know, that risk window, you know, you've probably heard that term before, time to patch. This is how quickly you can roll updates out to your environment. I didn't have it in this slide, but there was actually a really good article or series of articles that have now circulated about the Department of Homeland Security. Back in 2015, the Department of Homeland Security put out a mandate that all federal agencies underneath that umbrella had to adhere to a 30-day cycle for resolving critical vulnerabilities. They just came out a few weeks ago and probably announced that they've...the success of that mandate has been realized. The average federal agency under the DHS went from an average of 149 days time to deliver, you know, security updates to their environment, down to a 20-day cycle.
On top of that, they just released a new mandate this last month to say their new goal is now 15 days. So, you know, 149 to 20 days, it took a little while for them to get there, but they succeeded. They were able to get their average agency down to a 20-day time to patch cycle, and now they're pushing for 15 days. That number is not thrown together by mistake either. If you look at this threat model, there's always, you know, like I said before, software is inherently vulnerable. There's exploited Zero Days, there's public disclosures out there, meaning, enough information is out there that threat actors can start to build and attack. There's unknown vulnerabilities that, you know, haven't been identified yet.
So, on Day Zero, when an update releases, this is when the real race begins. There aren't thousands of Zero Days that are constantly popping up. They're a little bit more rare, but when they do come up, they're pretty threatening. The real challenge, though, is when an update comes out. We've now, you know, rang the dinner bell for threat actors to come around. They can see the update, they can see the original bit of code, they can reverse engineer that, do a differential and say, "Okay, here's where they change code." Well, if I go look at that, here's what they fixed. Reverse engineering that, an attacker can build an exploit. So that process tends to start to hit pretty heavily around this two to four-week period. The number of vulnerabilities that get exploited, you know, so if, you know, out of 100 vulnerabilities this year, 10 of those are going to be exploited. Half of those, 5 of those 10, will be exploited by the time you hit that 2 to 4-week window. Nine out of those 10 are gonna be exploited by the time you get to that 40 to 60-day window. So, to say that the DHS used to have an average time to patch of 149 days way out here, the majority of exploits that occur that attackers will develop, they were able to use in those environments for months before an update was put in place. That's just leaving doors and windows wide open for an attacker to come in. So, we've got to work hard to get down to that window, preferably down to a 14, 15-day time to patch. That's where you're gonna reduce the exposure time that attackers will have against your environment.
So, that's the importance of that time to patch and the importance of that 15-day number. How do we get past that? Well, we got to get better at identifying and automating the bottlenecks. CVE to patch, that was one of those bottlenecks, and that was a good way to automate burning another or, you know, reducing another day worth of time spent. Shorter test cycles, making sure that you've got clearly communicated stages to your test cycles, and that you've got more users participating, pilot groups. Microsoft didn't create the whole insider's program on a whim, it was a way for them to be able to get more users involved with the testing process. This is something that the industry has adopted as a best practice. If you're not using your own users within your organization during that test cycle, you need to look into that because they are your best way to test applications, resilience to updates within your environment.
Classifying applications that need to be done more frequently. So, in a lot of cases, you can boil it down to user-targeted. Your browser's, your media applications, you know, if it's Office or PDF readers, things like that those are the most highly targeted. Those applications also are a little bit more resilient to patching in most cases. So, maybe those applications should fall into a group that gets into a weekly patch cadence. In fact, we just had our interchange event that I talked about. We had our Madrid, our European version of that in Madrid, just a little over a month ago. And one of our customers that participated in our keynote, these guys have 66,000 endpoints globally. And the majority of that environment, anywhere that they've got users especially, those parts of their environment are being patched weekly.
So, you know, the...they didn't give me an exact number, but it was somewhere upwards of 50,000 of those devices are on a weekly patch cadence. And then there's other critical parts of the infrastructure that are patched more on a monthly cadence, but they do have a very tight time to patch SLA for those environments. But this is a 66,000 endpoint environment that operates at a global scale. There are retailers, they've got sites everywhere. And they're able to deliver security updates on a weekly basis. It's not because of some miracles that they figured out that nobody else has. It's because they made it a cultural change. They made it a mandate, and they made it a discipline within their organization.
All right, so around that, you know, this one's fairly standard. Most companies have some level of communication but making sure that your users are communicated. They understand the process, they understand the importance of providing updates. You know, if you're...I've talked to a number of companies where they're like, "Oh, yeah, we don't worry about patching things like Google Chrome, they've got updaters that updates itself." And my question to them is, "Okay, when's the last time your user actually close Chrome?" Because the update doesn't apply until Chrome gets closed, all tabs, all browser instances of Chrome. So, the importance of having your patch solution, know that Chrome is there and know that it's still out of date is to catch those cases. And to force that reboot cycle and to make sure that that actually got updated. Otherwise, a lot of users, they'll have 30 tabs open in Chrome, it'll be soaking up 80% of the memory on their system before they finally do something about it. So, making sure that you've communicated and educated your users on the importance of these types of notifications.
Also, this is an example of, you know, what we send out to our own internal organization. We also do variations of this for business-critical apps. So, our own DevOps team that patches the critical infrastructure that manages some of our core content and things like that, I get notified when those guys are patching those environments. As an owner of our Apache solutions and other solutions in our security stack that use content, those servers are part of my critical business line. And if they get disrupted, I need to understand what was going on there.
So, then keeping me in the loop on when those windows open, when they closed, known issues, if there's disruptions to service is very important. So, make sure you've got good communication and education around that. Well-defined SLAs, defined as exceptions processes, notifications for users to make sure that they're aware when the window is open when they close, what they should do if there's a problem, and then responsibility and accountability for these things. You know, going back to the Equifax example, you know, I...was the first radical article I read about that basically said," Yep, there was this patch administrator who failed to do their jobs. They've been let go, problem solved. This is not gonna happen again." And you know, as soon as I read that, I'm like, well, that's absolutely false.
You did not have a single person that had to push an update and install it that would have resolved this issue. That was more back on that DevOps process we talked about, but it was, there was no responsibility, no accountability, for where that decision really was. There was a business owner for that application, for that platform. There was a DevOps team involved in updating that platform as updates were needed. There were a number of people involved in that process. And the way that it was played off by the CEO at Equifax was a total blatant disregard for responsibility and accountability within that organization. And, you know, that's, just a prime example of where this type of thing breaks down, unless you make it clear, who's responsible for these things? Who's accountable? If there's an exception, at the end of the day, who needs to make sure that that exception gets resolved? So, make sure that those things are taken care of.
Another thing that, you know, we tend to focus sound a lot at Ivanti is make sure that, you know, you've got additional capabilities in place. Defense in depth is the only way to secure your environment. And patching, you know doesn't always solve every problem, you know, we've got Zero Days. So, those are exposed beforehand. You can't patch those until an update is available. Now patching itself, that's your number one, reducer on attack service, very simple. Most vulnerabilities in your environment are gonna be at the OS or in the software running on that system. Resolve those vulnerabilities by patching, great.
Now, what happens if I have an exception? Okay, can I use application control to block malware and untrusted payloads? This is gonna block a whole lot of what a threat actors are gonna use to try to get a foothold in your environment. The backdoor tools that they're gonna install. If you're familiar with Emotech, Emotech is a piece of malware that gets installed on there and it's basically a platform that now can start to do a variety of different things depending on where it is. If I would have had a good application neutral policy in place. I could have blocked that payload right away, even if it bypassed my threat protection capabilities like AV. So, those untrusted payloads can be blocked by doing a good application control policy.
Privilege management, this is how attackers now pivot and start to move laterally throughout your environment. Making sure that you've reduced user privileges, that you've taken away access to tools that threat actors are going to use like PowerShell and command prompts and other capabilities like that. That's where you're going to be able to stop them from turning and you know, stopping using malware and starting using your own credentials and your own utilities against you to basically move throughout your environment undetected because now they look like they're just one of you. So, these three things together...and the CIS framework that I talked about that group and done studies on this others, globally, like the Australian Signals Directorate, those guys did a similar study. They've shown that 85% or more of common cyber threats can be mitigated or eliminated by doing these three things well.
So, now going back to a state where we don't have enough data available yet, app-controlling privilege management are your number one and number two defensive mechanisms for stopping those types of vulnerabilities from being exploited. So defense in depth, if you don't have these capabilities in place, if you know that you've got the issue that we so lovingly call privilege everywhere, you know, too many users with full admin rights, you know, those are things to look into that complement your patching process and are able to help layer on those defenses.
All right, let's talk about a little bit more about managing exceptions and also end-of-life software. There's a whole lot of end of life software coming up right now. Windows 7, Java 8 just hit end of life, 2008R2 and 2008 are coming up. So all those in January next year, we've got sequel 2008 coming up on its end of life. Shockwave just reached end of life month ago. There's all sorts of applications that have reached their end of service, no longer getting security updates. And you need to know about these because every single one of them becomes a security liability if they remain in your environment. You also have exceptions, "Oh, I can't patch this application because it'll break a business critical application."
So here's a, you know, a number of different methods that you can use to try to mitigate the risk of that exception or that end of life piece of software that you know you have to hold on to for a while yet. Removing direct access, virtualized those workloads and segregating them from other parts of your network, removing direct internet access, if it doesn't need Internet access at all for that application, you know, moved at Internet access from that environment that you set it up in. And if the user needs to get anything like that they do it from their own workstation, not where this exception is now running from. Application containerization, if I can wrap that up, and if I can control what it has access to and limit it further, you know reducing user access or privileges to that application, making sure that only authorized people are able to run it, get access to it, or even touch the environments where it's at.
An interesting conversation came up if any of you are followers on patchmanagement.org, a gentleman posted a question on there of, you know, what do people recommend for securing, you know, this application after it reaches its end of life? So, they...there was a little bit of discussion back and forth about that. And I propose these options to see if they've already done that. And he said, "Yeah, no, we had that discussion internally. They were all rule to be too costly." Okay, so then the alternative is you go to the vendors, that end of life, the software, and see if they've got a continued support option to continue getting security updates for it, which also has a cost.
So, whether it's an operational cost or a financial cost, you can't walk away from security issues with an exception like this. If it's Windows 7 that, you know, you're gonna run for an extra six months after that, take those systems, you know, upgrade those users to Windows 10, virtualize a Windows 7 environment. And, yes, the operational cost of running Windows 7 over here in a VDI environment is additional operational overhead. But it's securing that environment so that it doesn't become just a free rein wild west for attackers to exploit.
Exceptions also should be clearly accountable, who is accountable for that? So, a bad...back to again, me being a business line owner for within our environment, I have responsibility for the operational servers that serve my business line. When the operations teams want to do maintenance on those, I'm one of the people that's consulted on that. If I come back and say, "Actually, no, sorry, you can't patch those right now." Who's accountable in that case? Well, not the person who was told no. It's the person who said, "No, you can't do that." So, I'm accountable. When does that exception gonna be resolved? If it's because we've got applications that are needing to run Windows 7, okay. You know, how long do we have to keep running that? Is it six months? All right, that's a long time period. It's not just a month or 2 months, it's 6 months, it's 12 months, 18 months.
In that case, we need to look at how do we take some of these mitigating steps and do that? So, does it require you know, what are those steps to make sure that that exception doesn't become a weak link that's gonna get us exploited? Is that are we dependent on a vendor? Are we in touch with that vendor? Do we know when they're gonna resolve it? Is it due to a shift in schedule? if it is, then okay. The new Window's over here, and then the exception will be gone. You know, so these are...you need to make sure that your exceptions include this type of information and who's held accountable. And that person who's held accountable also needs to understand the ramifications. So, you know, that hypothetical patch administrator that Equifax, like, go after their breach is not the person who should have been accountable there. The person who's accountable is the person who did not authorize that system to be updated to resolve those security for accountability. For whatever reason, financial, political, whatever else, the people who are making those decisions are the ones who need to be held accountable and understand the ramifications of their decisions.
All right, so, this is another one that's been going on for some time, what we call the follow the user issue. We have created a lifestyle that allows our users to work anywhere. And we wanna make sure that we can manage those users anywhere. So, if that user can leave the environment, we need to make sure that our technology can follow them wherever they go, to make sure that they're patched, to make sure they get policy updates to make sure that they return results and we can see clearly that those activities are being done properly.
Windows 10, you...the slide isn't updated here to now reflect that April 9th is long gone. But a couple of tips that, you know, you should be aware of when dealing with Windows 10. You basically depending on, you know, what branch you're on, what licensing level you're on, you're gonna have somewhere around 18 to 24 months on a branch, and then that branch upgrade needs to occur again. So, within the lifecycle of a piece of hardware in your environment now, you should expect that you're gonna have two to three branch upgrades of Windows 10 on that device over the course of its life. If you got a five or seven-year life cycle, that's very, very reasonable that that's going to be what you're gonna be doing. So, make sure that you've accounted for that, that you've got a good release process for this.
It's not a monthly patch cycle, it's, you know, a much longer life cycle. But if you're swapping out systems on a, you know, like, several hundred at a time, over the course of time, you're buying down the number of systems that have to be upgraded to the next branch before you get to the end of that project. And suddenly, you're coming up on, you know, November 12, you know, 2019, when Windows 10, 1803 end of life, and now you've got to upgrade 90% of your environment because you haven't done anything yet.
So, a couple of tips here, you know, one, make sure that you're tuning into an understanding where those branch life cycles are, two, make sure that you've got pilot groups set up for these that you're, you know, distributing the, you know, the branch to to get things tested out in that first six months after it releases. And then once you hit that six-month cycle, get your early majority deployed out, get your late majority deployed out and get your, you know, those critical devices that you don't wanna do right away. Make sure that they've got a good timeframe to get in before that end of life gets reached.
Another tip, there are two branch upgrades each year. There's the 09 or the 03 and the 09 cycle so, they spring and fall releases. 1903 just came out and so we've got 1809 and 1903 are the two that most people are kind of, you know, pushing towards now. If you...you know, read the full lifecycle details on their site, Microsoft clearly states that the fall release every year has, for those of you on an enterprise or an education license, that product will have a 13-month life cycle. So, you know, in that case, the 09 branch will give you an extra six months lifecycle on that branch. So, tend to get the majority of your systems on that fall branch every year, and you'll get a much longer lifestyle out of those.
All right, last bit here. So, another thing, we're trying to reach that time to patch up 14 days or less. One of the significant ways that you're gonna reduce that time to patch is to automate as many steps as possible. So, you've got complex systems in your environment, you've got clusters, load balancers, tiered applications, integration with your DevOps process where, you know, if you've got a development group, and they're pushing an application, and then they've got other third-party apps on that same platform, and that gets deployed out to production and gets tested before it gets out there. Well, if you do your patching, once it gets to production, you've missed an opportunity. If you do that in line with the DevOps process and make sure everything was patched before it got to QA, you're gonna be able to flush out and understand if there's any issues beforehand. You'll also bring that DevOps group into the cycle and have them better understand the vulnerability management there.
So those are all options where you have the ability to automate, create run books for and reduce the amount of effort your teams are spending on them. We do have an automation platform. For any of you using our patching technologies, you know, you actually have a standard version of this product available to you at no additional cost. So that's another option you can look into that will help you to automate and, you know, reduce the amount of effort that you're putting in each month. Because most of these systems, you're gonna patch, in the same way, every month, you've got a manual run book that you do today. But you've got people doing that work instead of automating it and that's going to delay time and effort. And those people, instead of focusing elsewhere, are focused on managing this button.
All right, so that wraps up our best practices there. If you do have any questions, I haven't seen too many come through yet, but if you do have any questions, go ahead and post those now and I'll be more than happy to answer those. And just as we're waiting for any questions to come in, we have another event coming up here very soon. On May 30th, we're doing a Windows 10 Summit. So, this is a combination of Ivanti and a number of our partners, and also, Microsoft is gonna be participating in this event as well. And what we wanna do is help companies to tackle many of the challenges of managing Windows 10. So, whether it's upgrading from Windows 7 to Windows 10, or it's the brand managing branch upgrades better, implementing and really taking advantage of the security features of Windows 10. We've got a number of partners and Microsoft coming to the event as well to speak about and share their experiences and talk about how you can better manage Windows 10 going forward. So, check that out. It's a free event, starts at 11 a.m. Eastern on May 30th. And, you know, throughout the day, there will be multiple sessions that you'll be able to jump in and out of, you know, whatever topics are of interest to you.
All right, I don't see any questions there. So, at this point, we're gonna go ahead and wrap up. I do appreciate... Oh, wait, we got one here. Question from Jerry, "When will driver of these become part of Ivanti patching? Dell, Lenovo." So, Jerry, this is depending on which product you're on. If you're on our patch for SCCM plugins, we do have the ability to import those Dell and those catalogs directly through our catalog there. So support is already available there. The...oh, yep. So Erica just responded with that next question. So, yes, if you're on that patch for SCCM products, those catalogs are available to import and be able to manage directly through our plugin. Right now, it's something where you basically...we have steps on our community on how to do that. In the next release, it's gonna be coming out later this fall, we're actually gonna provide those directly in the product where you just click a button and say, "Yes, pull that catalog in for me," so to be more content-driven here very shortly. If you are on our endpoint management platform, we take a very similar approach. Using those same catalogs that are available directly from Dell, Lenovo, HP, we actually pull those catalogs in and drive those into our EPM platform as well.
Great. All right. Next question from Eric, "How do you go about getting more user engagement during pilot testing for patches?" Okay, so here's one, and this will vary based on company. But one tactic that I often use is, hey, you know, go to the business line owner or the manager of whatever departments that that, you know, you wanna get a couple of tests users from and say, "Okay, you remember we've had challenges with updating this application and your users being impacted in the past, right? Here's what we propose. You know, we have test systems that are gonna try to replicate and test things out, but we need some of your subject matter experts, the people who know how to use this application well. If you give us a couple of your users, they'll be in our pilot group, they'll get patched first. And they'll be able to raise issues very quickly because they know how to get deep into the product and poke at those areas that are critical that need to be tested out." So engage with them on that level, hit them where it counts. It's your application. You're concerned about doing that. If you give me a couple of your users to add into my pilot group, we'll help you to make sure that we don't disrupt your whole part of your organization. And I found it works extremely well. At that point, you're partnering instead of enforcing and it gives good feedback.
Another question came in talking about if there's EPM customer who's having full scan issues hanging. So, we would definitely need to get a support case open on that. There's no just magic. Here's what you do. Couple of things that I can think of the top of my head, when we introduced the new patch engine in January last year, all new contents, so January 2018 and forward are on that new engine. If you've got a mix of pre-January 2018 and post-January 2018 content approved in there, that could actually, you know, cause some issues in there. So, you know, all those pre-2018 updates are superseded by newer ones. So, if you take those out of the approved list, you're still handling the security issues there. And a lot of customers have seen a huge performance increase for one because you're not using the legacy engine at all anymore, but it has resolved other issues. Otherwise, I would suggest making sure to open a support case and getting into more detail because we're gonna need details at a logging level beyond that.
Question from Yonish [SP], "Other than SCCM, what other tools does Ivanti support?" We at...so Ivanti has three patch management solutions. We have a plugin for SCCM that extends Microsoft to include our third-party catalog. We have our own endpoint management platform, similar to SCCM, that has a patch module directly integrated with it. And we have a standalone solution called Ivanti Security Controls. This would be a direct replacement for, you know, Microsoft or any other patching solution in your environment. The platform coverage for our own products, we do have support from Microsoft, Mac, and a variety of Linux platforms. So, if you're using like your SUSE manager or satellite or other products like that, and you wanna get to a single solution, we have the ability to manage cross-platform and be able to help you solve that problem.
All right, question from Hiyas [SP], "Ivanti cloud, a complete new product or replacement to current products? Using EPM today, how does Ivanti cloud compare?" So, the answer to this is more of a kind of multi-step evolution. Today, it's gonna be your existing product. So EPM is what you're on. But if somebody, you know, within this group is on SCCM or security controls, you're going to be able to use connectors that we're developing right now for those products. And that will connect your on-premises product with Ivanti cloud and be able to bring those two experiences together.
So, that patch intelligence feature that I was talking about, if you have that connector in place, you'll not only see our catalog of software updates and good reliability and risk data about it, but you'll also see your data from the on-premises product lined up with it. So, you'll be able to start to see all that come together. Now, some of these things are being built right now. The base patch intelligence experiences there. But even things like device reconciliation, we've got connectors for EPM, we've got connectors for SCCM, for Active Directory. We're gonna be building out more connectors for other products. It's a hybrid experience. Over time, we are going to build a pure patch solution that can be consumed directly from the cloud without EPM security controls, SCCM or any other patch vendor from an on-premises standpoint anymore. That'll be coming down the road. There'll be transition options available at that time.
Questions from Pym [SP], "Any intent on putting the driver management, I was talking about into security controls?" Yes. You know that is something that we have talked about quite a bit. We're looking at how best to address that and make sure that, you know, it's a kind of an overall good experience. Time frame on that, we don't have one defined right now. We're still working on getting a few other security modules migrated into security controls, but once we do that, driver support is definitely something on our radar. If you haven't already, I would suggest going out to our ideas portal and suggesting that out there or voting up. I know there's a driver support for security controls request out there, vote that up so that it helps push the priority up for us.
Question from Rohit, "Is this patch for SCCM available to use on EPM 2017.3?" I'm not sure exactly your question there, Rohit, but that CVE import feature that I was talking about before is gonna be introduced in EPM 2019.1. Patch for SCCM is our plugin directly for the SCCM platform. So that would be separate from the endpoint manager platform. The patch engine that we use in all of our patching technology, yes, that is in 2017.3 SU7. So, you are using our patching technology there. So, that should be available in there.
Question from Russell, "Can you recommend tools for checking development code for vulnerabilities?" So, there are a couple of tools out there. Many vulnerability assessment tools like, again, Qualys or Rapid7, those are going to be able to see those development components built into applications in many cases and be able to identify vulnerabilities from that standpoint. There's also some other assessment tools, one that we use internally here at Ivanti called Blockedup [SP] that can do assessments of applications to find out what components are in there and both from a licensing and a security perspective, give you an idea of risks to that. So, one thing if your development organization is using off the shelf software from like Nougat or GitHub or other places like that, or if you're using those types of open source libraries as well, that application not only looks for security issues, but also licensing issues where if you're using this, you could be entering into a liability issue from a code perspective where, by using these open source libraries, you're actually exposed to a need to make your source code for your application available. So it's that type of application looks at risks from both of those standpoints.
Let's see, I think one more here, Connor, "Does Ivanti support ForeScout integration for scan patch scope and discovery on the network?" We don't have any direct integrations with ForeScout. If ForeScout is doing discovery, and it's coming up with a list of systems that you want to be able to target. We do have API's within our products that allow you to basically take collections of systems from other sources. So, you can look into options like that where we can absolutely script integration options like that. If it's from a vulnerability perspective, if ForeScout has those CVE IDs in an assessment somewhere, that CVE import feature would absolutely work ForeScout as well. As long as you can get a report that has those CVE IDs, you'd be able to import that and use the prioritization from that product over in. So another one that I've talked a lot with some people recently about is a platform called Kenna Security. They don't do the...I don't believe they do the vulnerability assessments themselves. They take vulnerability assessments from any other vendor, and they do additional prioritization on top of that, but they have those CVE IDs in there. With that, we can use that in our product to then prioritize and identify the updates that need to be applied.
So, hopefully, that helped to answer your question there. Just going through quickly to make sure that I got to any other questions...like most of those. Yeah, mostly, the ones I'm seeing here around just relating to connectivity or audio issues. All right, well, we are a bit over time. I do appreciate everybody sticking around for some additional time there. I do apologize if I did miss your questions. There were a whole bunch of them in there. I tried to get through as many as possible. But thank you for joining us for this event. And we'll talk to you again soon.