Transcript
The discovery of common vulnerabilities and exposures, or CVs, has a tendency to induce panic in organisations that their data or systems may have been compromised. But when security companies identify CVs within their own solutions, it actually reflects a proactive and responsible approach to cybersecurity. In this webinar, brought to you by CIO and Ivanti, you'll learn why transparency about self-discovered CVs enhances trust with customers and the wider security community. The expert panel will discuss Ivanti's Secure by Design approach and the multiple customer benefits of delivering solutions and platforms based on these principles. Joining me today, I have two guests, Mike Reamer, Field Chief Information Security Officer for Ivanti, and Carl Treibus, Chief Product Officer for Ivanti. Welcome both. Would you like to say a few words to introduce yourselves? Yes. Thank you so much, Kathleen. Mike Reamer, again, from Ivanti. I'm the Field Chief Information Security Officer. I have 25 years experience in the US Air Force in military intelligence and cybersecurity. Retired. I then came into the industry, worked for Juniper Networks as their security solutions architect, and then over to Pulse Secure as their CTO, and now over here at Ivanti. So, thank you for inviting me today. Yeah, and I'll just go ahead and introduce myself, Kathleen. Thanks again. Appreciate your time here today with us. I'm Carl Treibus. I am Ivanti's Chief Product Officer. I'm actually a recent addition to Ivanti, just joined at the beginning of the year. I have about 34 years of experience in the tech industry, starting way back in the 90s in wireless, and then moving into networking, and then ultimately into application security cloud where I spent 13 years at F5 as a network CTO running engineering and product there, and then later over at AWS running the elastic block storage, and then more recently running the security business unit over at Apervo, which just recently was sold over to Talos. 34 years experience in the industry and about 20-some-odd in security specifically. Looking forward to the conversation today. Wonderful. Thank you. That's a lot of experience between you both. So, Mike, I wondered if you could perhaps start by giving us a definition of what CVEs are and whether it's something companies ought to be worried about if they've been identified. Sure. Absolutely. So, security vulnerabilities, we identify them as CVEs or common vulnerability exposures. And what they generally are is a weakness or a vulnerability that's within a product's code that allows for exploit, a way for a threat actor to use to gain access to a solution or to have a negative impact on those solutions. For the most part, CVEs are found internally. We do a lot of testing and a lot of validation and a lot of certifications that we have from within not only our static but our dynamic code analysis tools that help us identify situations within code that may lead to exploit. So, those are the types of things that we'll fix internally and then doing responsible disclosure and being transparent, we'll go ahead and publish those CVEs letting the defenders out there know that there was an area of the code that had an issue and that we fixed it. This does a two-pronged type of response to the market. Defenders have the ability now to understand that there is a weakness within the code, that we fixed it, but they can start looking for that within their defense mechanisms and their ecosystems that they have for security. Whereas, also, other software vendors can see where we had weaknesses within our code and if they have similar, they can then address it on their side. This comes really handy, especially with open source third-party tools that are used by many software vendors within their solutions. So, if we have an issue with it in our solution and we publish a CVE on it, then other software vendors can review it on their side as well and then fix it on their side before it becomes an exploit. The other side of the CVEs are those which come out as zero days. A zero day is something that is actively being exploited by a threat actor in the wild. It comes to our attention through threat actor behavior. That's when a customer says, hey, something is going crazy with my system. It's not performing correctly or I'm seeing inappropriate behavior by the solution. That's when we start to review it and that's when we find a threat actor is involved and found an exploit within the solution. And so, those are what we call zero day CVEs. So, they're definitely two different categories and customers should be responding to them differently. A zero day CVE is something that needs to be immediately taken care of. Mitigations need to be put in place until patch is available and then patching as soon as patch is available. For a regular CVE, which is one of those that come through responsible disclosure, transparency, these are ones that customers can review to see what the impact is on them. Do they have mitigations in place already? Is it an area of code that they're using? Is it a functionality that's exposed within their environment? Because a lot of times, those CVEs aren't directly exploitable based upon configuration. And so, customers should be reviewing those and then once they review those, then they can go ahead and plan a patch appropriately or put mitigation in place until they have the opportunity to patch. Thank you. That's a really useful definition. So, Carl, following up on Mike's points there, do you think organizations should be concerned if software vendors aren't disclosing CVEs? Yeah, absolutely. If you look in, you know, applications and how they're built today, they're generally built, they can be a combination of natively developed software, they can be a combination of natively built with open source or cloud services. It all depends whether you're on-prem or in the cloud. And as such, it really is a best practice for organizations and service providers, you know, to actively disclose these CVEs because they affect this larger community. That is, if we discover, if someone discovers, say, a flaw or a vulnerability, an undisclosed one, and let's say some, you know, third party open source, then it's a best practice to go back and report that. Likewise, if they find a vulnerability within their own products or their own infrastructure, they should disclose that. Now, obviously, they need to fix these things as part of that, but disclosure is important. And if companies aren't disclosing it, then likely they're not implementing best security practices. That's also an indication they don't have a robust security practice, you know. And furthermore, you know, likely they're not systematically addressing these CVEs as they come along. They're probably getting groomed in the backlog or they're not being looked at, but they're likely not being diligent about getting into the product. And that's key. If you're part of this larger community, you want to ensure that you're taking the steps and disclosing these things to enhance security overall. Now, the lack of security, these lack of security programs means, you know, many organizations are often taking an ad hoc approach and only addressing, you know, CVEs, you know, when A, you know, a customer has been impacted, or B, you know, discovery from an Ethel hacker and are under pressure, or C, they've suffered a breach or ransomware attack. And that's, you know, these are all not good, really. What you want to be able to do is be proactive, you know, and mitigate that attack landscape ahead of time and maintain a strong security posture. And again, the disclosure aspect of this is, again, kind of that, you know, canary in the coal mine, whether a company is serious or not, you know, with their security posture. And so, again, CVE disclosures, super important, helps build that awareness of risks that are affecting other products and services that organizations may be using their products and services or in their own IT infrastructure. So, at the end of the day, visibility makes us all stronger. Great, thank you. And to your point about taking a proactive approach, how can organizations develop effective strategies for managing CVEs? Yeah, so, you know, first and foremost, I'd say organizations need to think of the security team, you know, as a business partner. And that product or IT security is important as any other function that drives the business. You know, quality and security go hand in hand. And so, security should be a part of the corporate culture, you know, where security practices are integrated into the business processes, just turn it into part of that workflow. So, that's kind of step number one. The other key area is to identify risks within the product or IT infrastructure, you know, software assets, endpoint, storage, cloud resources, et cetera. And tool change that leverage, you know, such newer capabilities around risk management like exposure management, you know, are a good modern method to identify and help identify or excuse me, identify and prioritize those risks. You know, and finally, you know, once you've done that, you need to establish, you know, a process around best practices. So, a robust process around, you know, CVE management. New CVEs come in, they should be quickly triaged for impact. You know, as Mike mentioned, sometimes, you know, a high CVSS score or a high vulnerability score may not result, you know, may not be impactful. Often though, we find that, you know, maybe you have a moderate score, often hackers exploit these moderate CVEs. And so, you have to be very diligent in looking through and understanding how they may impact your infrastructure or the products that you're providing, you know, to your customers. The other key thing here too is that on-premise, it is very difficult for most organizations these days to maintain, you know, a very high performer or, you know, a security team that can anticipate all the different attack factors, especially for on-premises products. And so, they rely more on vendors. But one of the key trends, you know, in the last 10 years has obviously been, you know, security or, excuse me, software as a service or SaaS, and then consuming it that way. And I think it's important to consider this as part of your security posture is that, you know, companies that provide these SaaS services or these cloud services often have very, you know, well-established and deeply technical security teams that are out ahead and really watching, ensuring, you know, like vulnerable code is being patched ahead of time, you know, being diligent on top of that. With SaaS, obviously, you can do that at a very high frequency as compared to on-premise. So, you know, SaaS is a big thing. Often, they're employing the latest and modern components that are more resistant against these attacks. A lot of the exploits that tend to happen are code that's been sitting for a while or that's been out in the market for a while, you know, that wasn't necessarily built back in the day with the best security practices. And so, that's key. And then, the other aspect of SaaS is that time to response. You know, with a SaaS provider, they can do it very quick. They can do it at their cadence, which could be hourly in some cases. It just depends on who the provider is. But that time to respond is very key. You know, even if you're trying to manage it yourself, we keep that vulnerability window as short as possible. You know, a good example would be Log4J when it came out several years ago. On average, on-premise customers took over a week to patch their critical systems, you know, for that. And so, that's a big window for, you know, threat actors to get in and take advantage of that. And so, and if you look at like SaaS providers at that time, they were able to, ahead of release, they were able to, you know, block these vulnerabilities. So, in any case, it's something to keep in mind is when you're thinking about your infrastructure, what you're doing, don't think about just the business aspects or the, I should say, the business logic. It's how you're protecting your data and your business logic. Wonderful. Thank you. Great advice there. So, I wondered if you could talk me through some examples of customers that you've helped, Mike. Sure. And to kind of peg off of a little bit what Carl said there, that window that we have and some of the customers that we've worked with, as I said, you know, the difference between the CVEs, whether it's a zero-day exploit CVE or it's a responsible disclosure CVE, really has an impact on that window. And we've had customers that, you know, we've sent out, you know, what we call Patch Tuesday patches. We send them out the second Tuesday of every month, and we announce responsibly anything that we found internally within the code. And I've had customers that see those, and because the CVSS scores are in nines, they're critical. They're like, oh, I need to immediately do this because of that window, and they want to close that window. But actually, if they would have stopped and looked at the CVE and validated where the CVE was in the solution, many of them weren't even using that functionality, or it wasn't turned on, or it was behind an administrative privilege lockdown. So it was really only a CVE that would be impactful if you were on the internal network and had administrative rights into the solution. These are challenges that we have when it comes to working with the folks and customers and trying to educate folks to take a look at not just the CVSS score of a vulnerability, but look at how is it being announced. Is it being announced as a zero-day active exploit, or is it a responsible disclosure? And, you know, I said I had one customer that called me up, and we had done a Patch Tuesday, and there were several high CVSS scores in there. And they called me up, and they're like, so I'm reading through this, and I really don't see any impact in my environment. I'm like, correct. All you need to do is understand that we've released this. Go ahead and plan it for your normal maintenance cycle update so that you are patched against it. But they'd already had, you know, appropriate configuration in their solution to mitigate any type of harm from the CVE or exploitation. On the Converse side, we've also had customers that, you know, we've had active exploits in the wild. We had some in Q1 of 2024. We had one more in Q1 here of 2025. But I've actually had customers just in the recent weeks that have called me up and said, you know, there was a vulnerability in January of 2024. And I'm like, it's been 14 months. The patch has been out. It was all over the media. But yet, still, they don't see that. And this is the due diligence that we need to help customers understand. And as Carl said, when you have a SaaS solution, then you've got the vendor that is responsible for doing the patches and updates because the customer is just consuming it from the internet service provider that they're connected to the SaaS solution with. But when it's an on-prem solution, then we have to rely on people that are actually hands-on on the solution on a daily basis. And those edge devices, on-prem devices that we rely upon the customers to update, this is where they have to have the due diligence going out and looking at and reviewing from the software vendor the updates that are coming out and make sure that they have the mitigations in place or if it is a zero day that they're reacting and they're closing that window as quickly as they can. Absolutely. Thank you. I wondered if you could talk a bit about the problems facing governments in this space and how you've helped them navigate issues too. Yeah. So, you know, specifically with our VPN solution, it is widely used by some of the, well, not only the US government, but also many foreign governments as well utilize the solution, which, of course, for a threat actor, that's a prime target, you know, a governmental agency. So the attacks on the solution are very frequent and we see, you know, continuous attempts by threat actors to try and gain access. So what we've done is we do have capability within our solution to help customers identify if there's any activity going. A lot of folks like to look at that as the silver bullet for defending, but actually it's just one piece of the tools that customers should be utilizing to manage their attack surface and understand, you know, how threat actors are attempting to gain access into their environment. But yes, we've worked with several of the governmental agencies and helped them understand how the attackers are attacking them and made sure that they were secure moving forward. Now, one of the big challenges that we have with governmental agencies, as well as some large-scale enterprises as well, is their time to test before implementation. And this is where we're asking customers to be a little bit more flexible. When we vet and validate the security patches and we put those out, that's something that should be immediately put in place. That's closing that window of threat from that threat actor. So if it's a zero-day, we're patching, we want to close that window as quickly as possible. So that's when the patch is available. They should be applying it as quickly as they can. But we do have those governmental agencies and governments out there that require, you know, anywhere from 30 to 120, even 180 days of testing before they can put something in production. And that creates a challenge with the government. And so working with them, we try to put mitigations in place in order to block the threat actor behavior so they can go through their testing, and then we try to accelerate that testing as much as possible. But really, it is a challenge, and customers need to understand that we've vetted the security practice or the security patch to make sure that it won't have an adverse impact on the solution. And then we apply that, or we ask them to apply that as quickly as possible to close that window and create an opportunity for the threat actors. But we'll continue to work with those customers and continue to work on the flexibility that they have in order to do implementation. Thank you. It's a fascinating area. So I'd love to hear a bit more about what Avanti is doing with its ongoing work identifying CVEs. Carl? Yeah, so the posture that we've taken is the focus on what we call proactive security. And that really is a culture of maintaining what we believe are the highest standards of security and integrity. And this is in lieu of trying to wait for external researchers, malicious actors to uncover flaws. So as Mike was saying, we regularly pen test our products and our systems to find exploits. And we vary closely with security partners as we find issues or if we find issues to establish a fix for these. And we do this up front where we, like I said, we're not waiting around for someone to discover this. The other thing that's critical for us is that security is not something that's tested into the product. That is, testing exposes your security posture. And so you have to build that into your development workflows or your IT workflows. We call this, we use secure by design principles. And what this means is we try to leverage best practices around things like selecting memory-safe languages, such as Python, Rust, and Go as we look to new products. Again, going back to pen testing regularly, ensuring the best practice around development. We need to have code inspection and reviews up front during that process to ensure things like, hey, we're not making dumb mistakes like buffer overflow or issues or things like that. And then finally, as we look at the components that we're using, like open source or services, those all have to be evaluated as part of that whole dev process to ensure that we're not picking something that's buggy or has security vulnerabilities or it's not being patched or updated regularly, especially in the open source. The other key aspect of this is, again, addressing CVEs as a priority. As we see these come in externally or as we define them, we go through our process of establishing impact. What kind of threat is this? This is where Mike was talking about earlier. Something with a moderate security score, CVFS score, may not seem like it could have an impact, but you pair that with a couple other vulnerabilities. And often that's the approach that hackers are taking or bad actors are taking to compromise either your data or your system. They can find a way in. And I like to call these low and slow attacks. And I think these are the most difficult and pernicious to go deal with. And the key there is to stay up front and make sure that you understand what these CVEs are and that you're applying diligence as you think about that back end process. And that's what we're doing. Again, as part of this, we're prioritizing the safety of our customers and continuing to provide the best defense against these bad actors out there. Other aspects of this is that we do have committed security resources in our InfoSec and our development teams. We're doing regular security trainings, both of the security teams and our product teams, but the entire company. One big, probably one of the most easily exploited vectors is social engineering, where bad actors come in and misrepresent themselves in email, put a link in there, then you get malware, and that malware affects the systems. In fact, we're getting very clever in the age of AI. AI is getting better and better at emulating human behaviors and doing things that are clever. And so you have to be even more diligent. I got a text last week, and it was somebody masquerading to be our CEO and asking me to respond to that text. And fortunately, I know our CEO's phone number, and it wasn't it. So I was able to do that. But I don't know if others would necessarily catch that. And so these trainings are important. Anything that looks a little bit suspicious probably is. And so that's going to be key. And then finally, again, like I said, I'll just go back to the earlier point about you need to do this up front. Don't think that testing is going to catch everything. You need to be looking for these issues as you're developing, as you're deploying, as you're configuring various systems and ensure that you're maintaining that high integrity security posture. And that's exactly kind of what we're committed to doing to drive that. As Mike mentioned also, we have a regular process around Patch Tuesdays, where every month we're collecting everything and we're putting out a patch that patches all these vulnerabilities that we've identified as potential issues for our customers. If, though, something really big comes in, we will patch immediately and provide that patch and notify our customers as well. So it's not just on that monthly cadence. That monthly cadence helps kind of set a culture and a process around these regular additions that fixes to the product. But also, when there's a big issue, all hands on deck. We're going to fix it and keep our customers, mitigate the impact to our customers. That was great. Thank you. Mike, did you have anything to add there? Yeah, the only thing that I'll add is, as we're talking about secure by design, also you have what is called secure by default. And Carl alluded to it a little bit in his statement, is being up front and not only looking at the code and validating code, but from a product perspective, looking at the default configuration. So when a customer takes it out and first applies power to it and brings it up into an operational status, that that default configuration is as secure as we can possibly make it. It's been a habit of vendors in the past to create a default configuration that was open. So you would just plug it in and it would work. For instance, your home Wi-Fi routers. You'd go to the store, you purchase one, you bring it home, you plug it in, and you read the outside of the box to tell you what the password was on the default Wi-Fi network that was created. While that's great from a user perspective, it's very insecure from a threat actor perspective. They love to see default configurations. So it's our intent and our process that we're doing internally. As Carl said, we've brought in these community security resources, we've changed our internal processes, we've added extra testing and validation throughout the software development lifecycle process. Not just testing at the end, not just thinking about security at the beginning, but thinking about security all the way through the development process. Part of that is in that default configuration and making sure that an administrator is being notified if they're turning something on or if they're enabling a feature or functionality or they're deviating from the default, and it does open them up to some type of security exploit. We want to make sure that they're aware of that and they're making that conscious decision and they have other mitigations in place before they turn on those types of functionality. So secure by default is something that we're driving through our product portfolio. So as customers do stand up our solutions for the first time, that by default it is as secure as it can be, and then any modifications or changes the customer makes to it, if it makes it less secure, we'll notify them within the administrative interface of what's going on. Great, thank you. So I know that collaboration is important to you. Cole, I wondered if you could tell us a bit more about how Avanti is partnering with industry and government experts. Yeah, you know, security is just, you know, I should say threat actors are constantly evolving their attacks and they're very clever in many cases. So, you know, security or maintaining security posture, it's a fascinating landscape. And it's really important for organizations to stay up to date on the latest findings, you know, security exploits, as well as updated best practices. And so we participate heavily within that security community and we've engaged, you know, a number of the industries, you know, most recognized, you know, security and product development experts on security, you know, both governmental and non-governmental, you know, to support Avanti's team, you know, how we review our products, how we execute the guidance and how we meet our commitment to our customers. And so that, you know, the intent there is we want our customers to trust us, that we're looking out for their best interests with security. We're protecting their data, we're protecting their experience, and we're not allowing their systems to be compromised, you know, and so that's our focus as we work with these experts is to get the latest on the best practices, both, you know, in terms of like Mike's pointing out interesting aspects of disconfigurations of your products can have a huge impact on your security posture. So helping customer, you know, how ensuring that as, you know, as we're finding these issues that we're providing guidance to our customers on best ways to, you know, to configure, you know, also things like, you know, these CDEs that are coming in, that I mentioned that may not appear to be, you know, a high priority just because they have a low score. Like I said, often in combinations, they can become very, you know, malignant, if you will, an easy attack vector. And so understanding what others are seeing and how they're fixing or what they're, you know, out there helps us get better and stronger. And so again, you know, security is a community, you know, just like if you, it's interesting, you know, these threat actors are part of ad hoc communities as well. They share code, they take this, they'll build it, they'll modify it and do these different types of attacks, you know, and they're quite clever. And so it's really up to the security companies to stay ahead of that and, or I should say, any organization that's building tech products, stay ahead of that and ensure that they're, you know, applying again, you know, staying on that tip of spear and applying best practices to avoid problems in the first place. So again, very important to stay engaged, you know, with these other organizations or advisors or groups that we're already engaged with. Absolutely. Thank you. So I'd like to talk a little bit about some of the other aspects of taking the approach that you've outlined such as reducing technical debt. Mike, could I get your thoughts on that, please? Sure, absolutely. I mean, that's one of the things that we started out looking at several years ago. We started to see what we call code bloat. And this is something that are very common within the software industry. What ends up happening is you have, you know, a feature or function. Let's say it's an integration with a third-party solution. And you don't want to remove that integration because you still have customers using it. But the latest and greatest of that technology has now come out. So you add that to your code, but you never go back and really get rid of the old stuff because you don't know who's continuing to use it. And so what you end up seeing is multiple iterances or multiple versions of these integrations with older code or older solutions that never really get removed from your tech stack. And we call that tech debt. And its features, its functionality, its capabilities that are left into the code, most of the time it's for older legacy type of integrations or for older legacy protocols and communication type of software packages. These end up being the primary point for a threat actor to go after because these older integrations, these older code bases, these are the things that, you know, vulnerabilities pop up in. People find them over time, and they get published, and, you know, software vendors don't remove it from their tech stack. And so now you've got, you know, an old functionality sitting in there connecting to, you know, some 10-, 15-year-old backend solution, and the threat actor finds a way through that code. So that's what we call the overall attack surface of the software in that that old code or that tech debt ends up being the majority of that attack surface. Your latest and greatest and newest, as, you know, Carl has articulated our process for validating and implementing, that's great for the new features and the new stuff that we add, but it's going back and looking at that old stuff. And it may have been implemented in the most secure way when it was first implemented, but now that there are vulnerabilities in that protocol or there's vulnerabilities with that encryption hash, those are the things that need to be removed and taken out of the solution. It also helps to overall reduce the attack surface of the product so that threat actors have less opportunity to try and implement or impact it. And then it is truly that process of maintaining the security within your latest and greatest features because those are the ones that are present within the solution, and you've gotten rid of the old stuff. So definitely something that not only we are working on and continue to, but I know that there are many software vendors out there that are addressing tech debt. I think it was the Wall Street Journal published last year an article that said that it was a potential of about $1.5 trillion worth of tech debt sitting in today's software packages that are available on the market today. So definitely it is a challenge within the industry to remove. And again, it's difficult at times to understand what to remove because you don't know what your customers are using on the backend side. But if we could get customers to continuously update their backend systems as well as our systems, then we can remove that tech debt and be assured that everybody's using the latest and greatest so they're the most protected that they can be. Great. Thank you. That statistic really puts the scale of the problem into perspective. Carl, I wondered if we could talk a little bit about some additional benefits such as whether a greater focus on security and testing can also improve the digital employee experience. Yeah. Security and quality are essentially two sides of the same coin. And if you don't have a quality product, then the experience tends to be poor because there may be the system maybe rebooting or crashing or it gets slow or sluggish or creates other issues on accessibility. Same thing for security. If the system is slow, often, or excuse me, if security isn't present or focused on, let's say you're using a SaaS, it could be prone to things like denial of service attacks. Same with on-prem. That is, if you have problems, if you're not maintaining these systems in high security, then you may be prone to attacks that are exploiting data and removing that data or doing other kind of denial of service type attacks that affect the system's performance and behavior. And these things all affect user experience. And so by maintaining that security posture, that's going to help improve that experience for employees or your customers leveraging your systems or your products. Disruption proof is something you need to pay attention to because typically, imagine like an outage. Let's say you have a 30-minute outage in the middle of the day. You have 4,000 employees that can't access their applications. There's a real business impact to that, and there's a real impact to the user's experience that's trying to access these systems. It's very frustrating, and you need to maintain that high integrity to ensure that there's business continuity. So it really is that when you focus on security, you focus on quality, you do these things up front, then essentially you're doing all the best practices to avoid the outages or poor experience or business impact. That's something, again, that often isn't thought about. Security is often thought about as, oh, well, I'm going to throw this and pet it in my way or these gates. But really, it's for the benefit overall of the systems. And when we look at our products and when we think about security, what we're trying to do always is minimize the amount of direct impact from security processes or procedures in the products, being that integrating these seamlessly into your workflows or as part of your configuration or your operational posture ensures that you're not adding a bunch of arbitrary gates or testing or disrupting your work pipelines. It's ensuring that things are being thought out properly up front and being baked into the products instead of just tested in the end. So realistically, again, security indistinguishable from the notion of quality and in that user experience. Wonderful. Thank you. So my final question, I'd like to get your thoughts on how the threat landscape is changing and whether you have any final advice on what organizations ought to do to stay secure. Michael, could I start with you? Sure, absolutely. So the changing threat landscape, it is constantly changing. I've been in the industry for 42 years, and I know when we started out, you'd have maybe one attack a year that you would see, and it was from a predictable place where it was coming from. Now we see anywhere from a dozen to 20 attacks a day, and you don't know where they're coming from. Threat actors use botnets. They use ScriptKitties. They use everything at their disposal to try and make their attacks anonymous, so you don't know where they're coming from and you can't protect yourself against, you know, quote-unquote known bad IPs on the Internet. Threat actors are also, as Carl alluded to earlier, that threat actors are creating what we're calling cyber gangs. So you have the threat actors that exploit the device to get into it. Then they turn it over to another body that actually uses their skill set to infiltrate the actual system and then into the internal network and start doing intel gathering on the internal network, and then they turn it over to yet another group that will then use that network intel to go in and go after intellectual property or large data sources and either use ransomware on them or try to exfiltrate the data. You know, whatever it is they're trying to do, either from a profit perspective or for knowledge gain. So the threat actors themselves have created a corporate business and they are in it to do the most damage and the most information that they can gather. We often see threat actors doing what are called living off the land nowadays. So instead of just coming in and blowing your system up and disappearing, which is what we saw in the 80s and early 90s, now we actually see them coming in quietly. And the more quiet they can be, the happier they are getting into the system, being able to scrape and grab credentials of valid employees, valid users of the solution. And then what they do is come back later as that employee using those captured credentials and what they call, like I said, living off the land because then security doesn't catch them. It's a known user coming in, doing known user behavior, and they try to use the access privileges of that user in order to gain access internally into the network to try to get after things. What we do is we see this as trying to combat this from an organizational perspective. Least privilege access, putting in solutions that do provide you the ability to block specific users from gaining and having access to the entire network. Folks should only see the portion of the network and only have access to the resources with the level of privilege they need to conduct their business. I always use the example of 2 o'clock in the morning, the janitor comes in and logs in to see what offices he has to clean and what areas they're assigned to for the evening. We don't need that janitor having access to the banking information or the payroll information of the company. They should only have access to what they should have access to, and this goes for the entire employee base and doing least privilege access. For organizations, what can they do against the new threats that are out there, and especially we're seeing AI starting to be utilized, as Carl said before, threat actors are getting really good at phishing and social engineering, and they're using AI to help them so that it looks and feels like it's actually your bank sending you that email or communicating with you. But what organizations can do is really be more flexible, be more diligent, watch your software vendors, make sure that your software vendors are adhering to security practices, whether that's ISO certification or that's reviewing their SOC 2 Type 2 from a risk assessment perspective, but then also look at the knowledge base and the security notices coming out from that vendor and be diligent about them. When they have patches that come out that are addressing security concerns, validate them in your environment, make sure you have mitigations in place, and if you don't, fix that and then apply patches as necessary. And of course, if there's any zero day, then immediately respond to it and be as flexible as quick as you can to close that window of vulnerability out there. Great, thank you, Carl. Did you have anything to add there? No, I'll just comment on a few things that Mike said. AI, it has become a real tool and weapon out there for these threat actors to masquerade either as valid users or to continuously probe systems for flaws and vulnerabilities. I think back to, and I run a few of my own servers here in my house, and I think back 10 years ago, I remember I had to open up a management port, secure basically an SSH port, and that has a well-defined port number that would be on the network. What I found very quickly, though, within an hour, three separate threat actors from three separate IP addresses attempted to exploit the fact that that port was open, and they came in and tried to run well-known passwords or default passwords against it. Unfortunately, I had better security posture. I didn't have that. I logged these transactions, and I could see it. So it goes back to Mike's point about make sure that when you're deploying, that you're following all the procedures that the vendors are providing to you. Do not leave default passwords. Change your IP addresses. Basic things like that massively improve your posture. Look at who has access. That's another key thing. The organization should be constantly evaluating who and what, what level of access that their users have within that infrastructure, and then make decisions. And if they see behaviors, like let's say one of the big vectors out there is force. Basically, it's brute force attacks on your login site and threat actors will get through other compromised systems where users have passwords. They may reuse that password, let's say, and they will try those hashes against these logins to see if they can gain access. And so you need to have a robust program around ensuring that passwords are not being reused with your users, and you're using two-factor authentication, things like that. Those are kind of key ways to think about how to manage how users are using your systems. And then on top of that, the organizations that are providing products, such as us, to our customers, these tech products, we also need to continue to do our due diligence to make sure that we're staying on top of these vulnerabilities. And again, I'll go back to the earlier comment, that is be wary of organizations that aren't reporting CVEs and what they're doing about them. In a very quickly, let's put it that way, because we see a tremendous number of CVEs come in against, we have a very big code base over multiple different products. And so we're constantly evaluating, scanning, and looking at these to see what may impact us. Other organizations should be in that same posture. We disclose and we're staying on top of managing these threats and how they get integrated in the products. So I would just go back again and say, make sure you demand that from your providers, your staff, or your cloud, or your on-prem product providers. And that's how you stay safe, or that's how you maximize, let's just say, your security posture. And I'll leave it at that. Thanks, I think that's a really important final message to leave things on. Unfortunately, that is all we've got time for today. Once again, I'd like to thank my guests, Mike Reamer and Carl Trevis from Avanti. And thank you to our audience for listening. For more information on this topic, please visit the resources section on your screen. I'm Kathleen Hall. Goodbye.
