How Ivanti views patch management with a security lens

Formerly known as LANDesk, Ivanti has gone beyond providing IT management products and services over time, delving into the converging business of helping businesses identify and patch security vulnerabilities throughout the software development lifecycle while minimising the impact on IT operations.

In recent years, the company’s deeper move into the security space is timely with threat actors increasingly targeting and weaponising software loopholes to compromise their targets.

In an interview with Computer Weekly, Srinivas Mukkamala, senior vice-president of security products at Ivanti, shares how the company is helping organisations prioritise patch management and chipping away at the age-old problem of identifying unknown vulnerabilities and exploits.

Tell us more about Ivanti, which I understand has gone beyond supplying IT service management (ITSM) software?

Srinivas Mukkamala: Ivanti, as you said, has been evolving over the past few years. We’re the patch management leader and several cyber security companies doing endpoint detection and response use us. They all report on what’s wrong and what to do, but they don’t have the last mile and so they all use Ivanti as the last mile. That’s really the company’s history and claim to fame. That’s the evolution of bringing the best-of-breed patch management technologies together.

What people realise today is that patching without a security context is busy work. We’re patching for performance and security, but patching is going to break systems and that’s a concern for operations teams.

However, the past three years have been very interesting because of ransomware and APT [advance persistent threat] groups that have started using missing patches as a primary vector to be successful. So now, there’s pressure from compliance, governments and businesses to take care of your cyber hygiene. Ivanti is the best beneficiary of that because we’ve been working on this for 20 years. So, whoever has the best and the most comprehensive content from a patch perspective – we call it the patch catalogue – is the leader.

For example, we look at the reliability of patches based on test analyses and crash reports we collect on more than 250 million assets. And we can tell you, with confidence, that if you apply this patch, there’s a 90% chance your system won’t crash. Or, if you apply this patch, the reliability is low and so you might want to test it further. So, we fixed the friction from an operations perspective.

We also look at the patch from an attacker’s perspective. If this patch doesn’t exist, how can someone break into a network? So, we took that risk context and added that to our patch intelligence. For security teams, we can tell them the vulnerability and if the patch is being used by bad actors. We can tell them if it’s tied to ransomware or used by APT groups.

For operations teams, we give them the context that if they apply this patch, they are going to shrink the attack surface and fix the vulnerabilities. They are going to eliminate threats on their network. So, we truly brought the development, operations and security teams to look at the same data but presented in their own personas.

DevSecOps is a culture. You got to practice it. You got to believe in it. It is not about buying tools and technology or throwing people at it

When you look at ITSM alone, this is where the interesting merge comes in. Ivanti had their own ITSM and bought Cherwell to do other parts of service management. Cherwell has some very good employee onboarding, employee experience and a few other things. The joining of the forces of Cherwell with Ivanti’s existing systems made us one of the best in the industry today. In ITSM, the game now is between ServiceNow, BMC and Ivanti. And then you see a long tail that includes the Freshdesks and Zendesks of the world, and then of course, Jira, from a DevOps perspective.

From a device management perspective, Ivanti bought MobileIron because of their security controls. When you do device and patch management, you often do it in ITSM. With MobileIron, we’ve brought together three best-of-breed technologies that take your organisation into a converged mode with cost efficiencies and enable you to approach patch management with a security lens.

What Freshdesk or BMC doesn’t have is device management. BMC uses us for patch management and ServiceNow doesn’t have device management, strong discovery or patch management.

I’d like to zoom in on the point you made about the contextualisation of patch management. Companies often have priorities when it comes to patch management and that’s really tied to their risk appetite and the assets they’re protecting. How can companies take into account their risk management framework on your platform so that they can make better decisions about patch management?

Mukkamala: You hit it right. Risk is a differentiating factor today and a lot of people used to look at patching and security as a cost centre, but not anymore.

Let’s say you’re in Singapore and you take a risk management framework that differs from someone in US or Europe, but we can all agree on the top 20 controls. You will also want data supporting your risk profile. Having a vulnerability itself is not bad – which software is not vulnerable? But a vulnerability with a threat is bad – if somebody took time to weaponise that vulnerability, which means spending time to write an exploit for it, then it’s a matter of time before it’s exploited.

And if that vulnerability is present on an asset that’s important to you, then that’s where your business comes in. We call that “vulnerability threat impact” or VTI. Although you don’t have control over vulnerabilities, and threats are uncovered by threat actors or a penetration tester you hire, you can completely control its impact because you can control where your data resides and how it transits.

The key is bringing them together to give you a clear understanding about your assets – the software running on those assets, users and APIs [application programming interface] that have access. That’s really how we profile risks, which we determine at the vulnerability and asset levels. Then we’ll tell you what the applicable patches are. That will help you to not just report on VTI, but also remediate on vulnerabilities to reduce your attack surface and overall risk to your business.

In our conversation so far, we’re assuming companies are dealing with known threats. What about unknown threats or unknown unknowns for that matter?

Mukkamala: That’s the hardest problem, right? When I ran the cyber terrorism program for the US, one of the challenges I had was to find the unknowns and the blind spots.

Today, we look at weaknesses that allow us to discover vulnerabilities through bug bounties. In my humble opinion, that’s too late. Yes, we have the crowds helping us find those unknown unknowns. But it’s a superhero syndrome. They find the bug, get paid and move on. They don’t disclose that to national vulnerability databases. They share it with the guy who’s paying and keep it within the family.

In our case, we partner with cyber security companies which may tell us there are 54 zero-day vulnerabilities. They probably know 300 zero-days that they’re not telling anybody. So, you see the interesting conundrum here? The unknown unknowns are the hardest and, unfortunately, we don’t have any automated way to find them.

One way to look at the problem is from a philosophical perspective. Think about the reverse of that. Once we know of a weakness or vulnerability, can we predict if somebody will weaponise it? Because if we have enough signals that show certain conditions exist, then there will be an attacker who will take time to write an exploit. We can help you prioritise it because people are talking about it. That’s a known known.

The security guys live in both development and operations. That's where the sky is falling. Everything is a problem

Then there’s the known unknown, where it’s known from a vulnerability standpoint but unknown from an exploit perspective. In that case, we can give you an early warning, saying that if you don’t look into it, it’s going to be bad, and we have enough data to support our predictions.

Then comes the complete unknown unknown where we don’t know if there is a vulnerability or an exploit. You have to revert to fuzzing and look at what weaknesses there are. Do I have access to the source code? Do I have access to the software bill of materials? Or do I have access to development testing?

In 99.9% of the time, I don’t have access to the source code. I also don’t have access to the software component analysis because of the use of low-code and no-code development. I also don’t know what libraries or software components are being used unless somebody discloses that to us in the case of Log4j and Spring4Shell.

All you’ve got is Dast [Dynamic Application Security Testing] and you have a plan for access to software. So, you keep fuzzing to see what weaknesses are present and say, with confidence, that the vulnerability will be disclosed. If it is disclosed, then I can mitigate it as a known unknown and known known. That’s really how you solve it – it’s a sandwich model.

With the growing adoption of DevOps and the faster pace of software development, how is Ivanti helping organisations prevent vulnerabilities from surfacing in the first place?

Mukkamala: We started what we call DevSecOps as a service because DevSecOps is still a mystery. If you talk to 10 people, they’ll give you 10 different answers. Everybody will throw an infinite loop at you with 40 tools and say they are doing DevSecOps.

The right thing to do is take a step back. DevSecOps is a culture. You got to practice it. You got to believe in it. It is not about buying tools and technology or throwing people at it. I’m very clear on that. It’s extremely important to see it as continuous process improvement.

The way we look at it is you have a shift-left and shift-right syndrome. What is the right balance? Nobody knows. It’s very specific to your organisation and your skill set. With shift right, you have 90% of your code operational and running. You’re doing bug bounties and penetration testing and you’re telling your developers what to fix as you find things.

The security guys live in both development and operations. That’s where the sky is falling. Everything is a problem. On the right side, they do penetration testing, application security testing and on the left, they want to see your coding style and what weaknesses you’re introducing and the libraries you’re pulling.

The best way what we have seen is to use tools such as GitHub, GitLab and Bitbucket. Start looking at native tools and see if they have any ability to report on weaknesses and vulnerabilities. Dependency checkers will tell you that you’re using an older version of a software, for example.

The key is to look at weaknesses that have been introduced. That’s your first step, from code commit in your IDE [integrated development environment] to a branch where you cut it and when you merge branches to deploy it.

So, you have three places where you can truly have visibility. Let a developer know if he’s writing bad code, report that to the security guy so he feels included and tell the operations people not to deploy it if it’s bad code. If you missed that, then you can use tools like Sonar to do a code analysis.

The challenge here is that people are spending money on all these tools, but they don’t have expertise. How do you make sense of events? Well, tough luck. You’re paying a million dollars for licensing and you’re not getting value out of that. And by the way, there’s not one person who’s built all these tools. You’re talking to multiple people and you’re taking developers out of development and putting them into this tool chain. So, the first problem we hear is how do we integrate all these tools, so they all can play well with each other?

The second problem is data overload. All these tools are producing enormous amount of data. Where do I start? Where do I prioritise because I don’t want to distract developers with all this data overload?

The third problem is, once I figure out the data overload, how do I even prioritise this? How do I act on it? And how do I ensure I don’t make a mistake again? And finally, how do I even manage this whole thing? That’s where you actually see a big movement on DevSecOps as a service, starting with integrations to bring all these tools together into a common layer.

In DevSecOps as a service, you can diagnose and test from an application security, correlation and orchestration perspective, giving you visibility into your application lifecycle, from code commit to runtime. I see this becoming a very beneficial service for those who can afford it, while the have-nots will be staring at their screens and figuring out why they are left behind.