Hello and welcome to our Videocast today. I'm John Tolbert, Director of Cybersecurity Research here at KuppingerCole. And today I'm joined by Josh Gorrell from Tanium. Welcome, Josh.
Hi, John. Thank you for having me.
Well, would you like to tell us a little bit about yourself and Tanium?
Sure, so I work at Tanium. I am on the product marketing team and I lead our incident response solutions. So the Tanium platform really is the market's only converged endpoint management solution that is purpose-built to give security and IT teams complete visibility and control of their endpoints. And we're really on a mission to eliminate silos between CISOs and CIOs by giving them the power of certainty. And we're doing that by giving them real time endpoint visibility at scale to do end to end management of these endpoints. And then what we're going to talk about more about today is that round trip remediation. All of that is done from a single platform.
Interesting. Well, let's talk about incident response. We should probably just dive right in and talk about some of the most common threats that require incident response. So I'll toss a few of them out there. Things that are top of mind for pretty much everybody in industry, I think are ransomware, data breaches, and DDoS or distributed denial of service attacks. What other kinds of threats do you see with regard to the need for incident response, Josh?
John, I think all of the attacks that you mentioned remain at the top of the list generally. I think that... what I think is interesting is the evolution of some of those attacks and the characteristics of them. So ransomware, for example. I guess you could say ransomware 1.0 is where an attacker would keep that data hostage, but that data wasn't necessarily leaving the environment. Now we're seeing organizations that are under the scenario of a ransomware attack where that data is held hostage, but then it's also threatened to be exfiltrated outside of the environment and shared with parties that don't have access or an authorization to use that. Another thing that we're seeing with respect to ransomware is this ransomware as a service where attackers are basically farming out their commodity use of ransomware and it's being distributed out at scale. It's a kind of spray and pray, let's just blast this out, see where it sticks, and it is effective. That's really wreaking havoc. Of course, you see zero days. They're always making the headlines. There's lots of unknown in these attacks because there's very little intelligence about them. There's not a lot of history. There's certainly something to be aware of in the threat landscape, in the evolving threat landscape, but it's also the known common vulnerabilities that remain unpatched and unaddressed that continue to inflict a lot of negative impacts on organizations. So while we have some new, the same old tricks are still effective. And then another piece that I want to talk about as far as something that's new and we're seeing more of is in this supply chain and software supply chain vulnerabilities and the expansiveness. How much how much new ring that adds to the threat landscape. When you think about supply chain, it can be thought about from a physical standpoint, like your third party vendors and partners, but you also look at the software and the applications that organizations are using and the codes and building blocks and components within that software that may have vulnerabilities in areas for attackers to exploit.
Yeah, there's so many different kinds of threats and you're absolutely right about ransomware. It just seems like it's gotten out of control. You know, it's so prevalent. So many different kinds of companies are being hit. I remember back when it kind of first took off and it was a nuisance, it would lock your screen or something like that. And then they started going after individual users, wanting fairly small amounts of ransom, and then it became, like you said, corporatized. There's a business model around it. You had like APT actors doing destructive wipers, they would masquerade as ransomware. But they didn't really want ransom. They would just go in and delete all the data or destroy machines. And then, yeah, now you've got the extra threat of leaking data. And there are even some cases where malware may not actually be deployed that encrypts. They just copy the data and threaten to leak it. So there are so many variations on what we call ransomware today. It makes it much more difficult to guard against and certainly requires a good incident response plan. You know, there, like I said, there's so many different industries that are hip. We think of manufacturing and critical infrastructure, but, you know, healthcare has been widely hit, you know, particularly in the last few years. Cities, states, just all kinds of organizations, not even commercial. And we know that this requires vulnerability assessments and patching. We've been talking about the need for patching for many years too.
That's right. For security teams, it feels like a continual game of cat and mouse, even at the foundational level of vulnerability, discovery, and patching. Those are the basics. And as you mentioned, the reality is that no one is immune. The largest global multinational organizations to local, regional, healthcare, even national governments are making the news. So no one is immune from this threat, really.
So I know from working on another report, Fraud Reduction Intelligence Platforms, that healthcare organizations are targeted to get PII or PHI, personal health information, for the purpose of building fake accounts. You know, and these attackers not only are using information from data breaches, but they're leveraging things like AI, and in particular, generative AI for additional kinds of attacks.
Yeah, that's right. It's kind of that gen AI and AI are really popping up in every conversation in technology and especially security. And it's really two sides of the same coin from a vendor and solution provider standpoint, how can this be used for good? But then when you look at the other side and from an attacker's perspective, how is it being used for bad and what risk does that introduce into my organization and my customer? So, from an attacker's standpoint, how are they leveraging those AI and gen AI capabilities to bring the next level of attack to bear? But then for the organizations defending those, how do we use that same technology in different ways to drive the next innovations and transformations forward for cybersecurity?
Yeah, and just to finish up on the different kinds of threats that are out there, you know, let's not forget things like physical access violations and remote access incidents. You know, we've seen many interesting cases over the last four or five years where attackers go after unsecured remote access connections. You know, there have been several that we could talk about there and even involving critical infrastructure. And these situations lead to data breaches that could expose information about your customers, your company, or in the case of things like critical infrastructure, could lead to very disastrous consequences. So we can drill down into a little more detail on that in a few minutes. So now let's turn to think about some of the regulations that mandate incident response programs. We've been aware of things, privacy regulations have been big drivers in cybersecurity for a number of years. We go way back and look at things like PIPEDA in Canada, of course GDPR in Europe, and even in the United States, we've had multiple states that have different privacy regulations that more or less require incident response processes in the case was where breaches have been found. So there are some differences in the way these privacy regulations are laid out, what the requirements are, the obligations for reporting and whatnot. But one thing that's pretty common amongst all of them is if you find a breach, you've got to report it.
That's right. And not only do you have to report it, a lot of those reporting times are pretty tight. So once the alarm bells ring, a lot of times you need to have a comprehensive understanding of what's happening within 24 to 48 hours and communicate that up to required parties. So, I agree you're seeing these things, these regulatory frameworks and requirements pop up around the globe. In the EU, on top of GDPR, things like NIS2, the Network and Infrastructure Security Directive. In the US, we've recently seen the Security and Exchange Commission rules for public companies to report breaches. And what I think is interesting here is that it's not only reporting those breaches to external, internal and external regulators, but now for shareholders and other public stakeholders of those companies. They must inform their stakeholders of the events, the impact, the resolution plans to overcome that incident. And as we mentioned, those turnaround times typically are 24 to 48 hours. And in the heat of the moment, that's going to go by very quickly.
Yeah, you know, and some of these regulations can carry pretty stiff penalties. You know, GDPR and NIS2. You know, I think the numbers are something like 10 million euros or 2% of your global turnover. So you know, these are more than significant in many cases.
That's right. And I'll take, we could take it a step further now in that we're actually seeing this play out in real time where individuals are being held criminally responsible for not having the proper protections and response mechanisms in place as leaders of their organization. And so we're awaiting what the outcomes of those will look like judicially. But on the fines, I think that's, it's all relative, right? Like you see these massive numbers coming out for fines. You mentioned it, $10 million or 2 % of global revenue. That's relative. I think, I think it's relative in a $500 million fine for a Fortune 500 company is one thing, but a $5 million fine for a small or medium sized business could be crippling and take it out of business. So the impact can be felt differently by different organizations, regardless they are serious considerations and not pleasant for any organization.
Yeah, fines can be pretty stiff in a lot of these cases. But I mean, there's also just the threat of what ransomware does. I mean, I know cases where companies have been shut down for two months. Can you afford to have all of your employees idle more or less for two months? No, I think that ransomware data breaches are an existential threat above and beyond what the penalties for noncompliance on the reporting are.
That's right. And we've taken kind of a negative doom and gloom slant to this. But I think that I want to just point out that there is a silver lining here. At Tanium we've seen customers be able to leverage their ability to meet these regulatory compliance requirements and demonstrate a strong security posture and use it as a competitive advantage and differentiator to win business. So, for example, if you're a large vendor, or if you're a vendor in a larger supply chain with an end customer, say, that is a national retailer, to earn that business, you need to show and prove that you have strong security mechanisms and processes in place. And these are table stakes that you need to be adhering to, not only for the regulatory piece, but then you see it as you're going out and seeking new business, how that can be a real driver to success. And if you do this, if you prioritize this and you can confidently go out and do that, then there's a lot of upside to taking a more positive approach and attitude to why these regulations are being put in place and what the upside is to following them.
Yeah, good point. You know, a good incident response strategy and the ability to execute can be a real service differentiator. What do you see as making up a good incident response team? What are some of the key players you would find on an incident response team?
It's a really good question because I think tactically you think about like the CISO and the SOC, but I really like how NIST 800-61 outlines the key players, and that's NIST Security Incident Handling Guide. They break it into... the stakeholders into core internal groups and then other external groups that all play a part in incident response. So internally, as we mentioned, we think about the CIO and the CISO leadership and the teams that they're responsible for. So that's the SOC teams running the security operations, getting this thing contained and then working collaboratively with the IT team to solidify the environment. But then when you're looking more broadly at the org chart, even internally, how is the board involved in incident response? And what are their responsibilities in this type of scenario? And then looking laterally, how are your legal and risk teams involved? Then moving from internal to external. You have incident reporters, so looking at US CERT, or you have third-party incident response teams, your managed service providers, you have software and technology partners like Tanium. All of these organizations have resources and methods to helping support during an incident if they're properly planned for and tuned and ready to be activated. So the group of stakeholders, it can be expansive. And ensuring everyone knows their role and how to activate when these incidents arise, I think is critically important.
For sure. We could also add into that security analysts, the forensic investigators, and system administrators, the people that have to sort of clean up after an incident, [...] machines, probably go around patching other machines, you know, those at the technical level, plus communications. I mean, it's good to mention legal and risk and executives, but, you know, the communications team, I think, is really important as well for not only managing the reporting to the proper authorities, but also what do you tell the public? What do you tell your employees while this is going on? I think it's really key to know what you can and should say at each given point during an incident or a breach.
I think that's a great point. Now we've gone so far away from the SOC and a security analyst, but now we're talking about your PR and your media teams. How do you respond to the media? What is your message to articulate that the issue is under control and that you are stabilizing and maintaining resiliency in the organization and your ability to meet business objectives and customer demands?
So what would you say are some of the best practices for incident response?
You're going to double down and say getting buy-in from the top and shifting the importance of cybersecurity left, if you will. So incident response is a component of that. That's not a new motto, but make security investments. Make sure you're making the right security investments. Make that a priority, both from a time and a money, from a money perspective. We recently, Tanium recently conducted a survey where 8 in 10 professionals, so 80% said that the cybersecurity budget was only likely to be assigned or increased following a data breach, not ahead of one. So again, it feels like you're always playing catch up or selling the importance. You don't recognize the importance until the risk is real. So you're buying from the top. Try to shift that left and not be playing catch up when timing is critical.
Yeah, I totally agree on that. And if you can find case studies about others in your industry, like mean time to detect, mean time to respond, what the costs were. That can be useful information for making the case of, you know, buying on the prevention and detection side rather than, you know, having to wait until there's an incident to respond to. But, you know, having an incident response plan, team, and working that out is very, very important in our landscape today.
That's right, John. I think it's really important what you mentioned. Like, make this real and get case studies and get actual scenarios where this is where this has happened. And make it specific. Make it meaningful to me. So if I'm in healthcare, or if I'm in finance, give me scenarios or real examples where a healthcare organization went through this and where they found success. Or where a finance company went through this and slipped on certain pitfalls. How do you identify those pitfalls and avoid them? I think that that's great advice as far as that planning piece goes.
Yeah, it's always good to quantify it if possible. I think that really helps with justifying purchases for security products in general.
That's right. Other best practices, making sure that you're preparing the environment, making sure that you have full visibility into every single endpoint, every single system within your network. You can't protect what you don't know exists, I think is the bottom line. And then once you have that visibility, understanding your maturity and what's realistic for your capabilities. I think there's a kind of a basic middle and advanced level here. And I touched on kind of the basic ones. I can detect hygiene issues and I know what's on my environment and what does normal operational activity look like and how am I alerted to when those best practices and norms are not followed? When you take that step up and you're looking at capabilities like when my red team emulates a real world adversary, I can detect their intrusion at multiple points along the kill chain. I am understanding threats, adversary behaviors, and the ability to hunt. And then at an advanced level, during an incident response, I can operate at the same tempo as that adversary to protect my business, to protect my business assets. That's blending the people and the technology part, which I think is really important too. The recent Verizon DVIR report said that 85% of breaches involved a human element. So humans are very much in play here and need to be addressed and in the conversation proportionately. And with that, I'll just say keeping development collaborative, development of the incident response plans and actions and exercising those muscles, keeping that collaborative, promoting ownership across the stakeholders and not making those plans in silos and making it shelf wear where it's bound to get lost and lose relevance.
You know, I just want to add two things on the best practices. One is know your law enforcement people that you need to get in contact when something happens. It's better to make friends with them before an incident happens and really understand what their expectations will be from you. And then also, it's hard to forget, although it does happen a lot, backups. Backups are important. There's cloud backups, but cloud backups can be compromised in ransomware attacks too. So you need a good backup strategy that ensures that your backups will be available and then to test them as well.
That's right. When the alert starts going off in the middle of an incident, don't let the first time you've engaged with these security and IT and leadership folks, don't let it be in the middle of that incident. Make sure that those muscles are exercised like we talked about, whether that's through, this can be done through tabletops, through mock breach scenarios. Also, I mean, at the basics, sharing the documentation, making sure that folks know what those are, they bought into what that, what that plan is and you're ready when it matters.
So let's talk about how we measure success when you're doing incident response. What do you think are some of the key metrics that we should be looking for?
Lots of metrics out there. I think that you need a consensus of definition of done. I think that looking at that internally, but also what is the definition of done from a regulatory or compliance requirement. That should be a mutual agreement between IT and security and executive leadership. But as far as the finish line, I think that varies based on role. You have your SOC analyst who is looking to work very tactically to contain and isolate a threat or to mitigate the threat. And then meanwhile, you know, the CISO is looking much more holistically and maybe at the longer tail of responsibility of what that looks like and making sure that incident now that it's contained by the SOC, that those, that the forensics and investigation is done and you have a root cause analysis and can share that with IT and fully solidify that vulnerability. From a metric standpoint, I mentioned there are a lot out there. Some of the most used ones, I think, are mean time to detect or mean time to respond. How do you understand what your false positive rates are? Making sure that you're chasing or you're tackling the right alerts and not being distracted by noise, frankly. And when we think about these in particular, they're always a, you're looking at how fast you can identify and respond and eliminate the threat. On the detection piece, I think that that's a big piece of those mean time to detect, mean time to respond. We've talked a little about SIEMs and EDRs and advancements that they've made, but recent reports have also shown that they fail and that 63% of detections are sourced externally. So that means that the incident or breach notification is not coming from a customer SIEM or EDR tool. It's coming from the adversary or an external partner that is alerting them that something bad is going on in your environment.
Yeah, that's a good indication that you need more on the detection and response side. And I think it's good to remember the response, the mean time to recover or remediate. And then cost, can you figure out what an incident actually cost you? I mean, we see lots of different estimates. Of course, the estimates are always changing for what the cost of a data breach. But it's probably the most important factor in being able to get additional funding to prevent the next one. If you can adequately quantify what a cost of the breach is that your organization has had already. From your perspective as a vendor in the space, what do you see as some of the trends, and what do you predict for the future of incident response?
I think we're seeing more and more appetite for automation. And that's really where the future lies for Tanium. When you're able to combine real-time data and the ability to act on risk with confidence, that is where I think we're seeing real transformational change in capabilities with respect to incident response. It's representing a quantum leap for organizations looking to not only mitigate the risk and manage their environments, but to continuously improve their security posture. So automation is helping not only with the security shortage, with the security skillset and expertise shortage, but also once you have those folks on board, how can you lessen the noise and really change what their day looks like? And then on AI, and gen AI, we've brought this up a couple of times already, but with... We have really strong partnerships with Microsoft at Tanium and their complete security stack and recently launched integrations for co-pilot security. And these are the types of innovations that are really transforming what security teams are able to do, what their day looks like, what their life looks like, and how we can make their security more impactful for the organization. This automation, it's really dependent though on the data. You need quality data and piping and integrations to make this happen. I think about for customers and their appetites for automation, you think about like self-driving cars. If you're in a self-driving car and it's looking to make a lane change, you need that car to be assessing data at the smallest fractions of a second to make the right decision. It can't be based on information that's one to three seconds old. And I think that the reality for automating elements of incident response, the same lies true in that relevancy and recency of the data. That's foundational to really diving into this automation and AI world as a next step.
Yeah, I would definitely agree with that. I think there's a lot of different ways AI can be helpful here. Like you're sort of alluding to with generative AI, coming up with descriptions of incidents and sort of keeping that alongside case management can sort of help the junior analysts get up to speed on what's going on. So there's lots of room for improvement. I'm sure AI will be part of it.
Absolutely, whether it's junior staff or new staff who aren't intimately familiar with these environments It's going to help them get spun up and begin tackling those security issues faster and then on the more seasoned folks that are real experts and know your environment intimately, how do you empower them to do more? I think that those are, especially during scenarios like responding to incidents, that's where we're really seeing some really fascinating impacts in development. Other trends that have supported this, that have been around, we've heard about security, excuse me, orchestration and automation platforms and SOAR specifically. How are you streamlining these response workflows, how are you opening up your appetite to let your workflows and playbooks take more of the process before humans are involved? I think that comes with practice and confidence. And then as far as the last turn, I just want to hit on again the supply chain and the response to these supply chains attack, whether that's in the physical sense or the third party software and deep within the code of your software applications. These are oftentimes the heartbeat and running critical functions of an organization and you need to be able to go deep and wide now with respect to the threat landscape.
Sounds good.
I'll close on the trends. I think that all of the incident response conversations roll up to keeping the business on and running and emphasizing that resilience, whether that's through defense in depth strategy before bad things are happening or taking that look back to doing the root cause so that you're driving resiliency and learning from your mistakes. And that when you get knocked down, that you are confident that you can quickly get back up.
So I think the big takeaway is that even if you don't have an incident response plan, it's time to start thinking about that, especially given all the ransomware that's out there, the different kinds of data breaches that we've been discussing, and just the multitude of vulnerabilities, and then the fines for non-compliance to the regulations that we've been discussing. Any other thoughts on that?
I love that saying, if you fail to plan, then plan to fail. Maintaining centralized documentation. Don't exercise this muscle in a silo. Make sure that all the stakeholders know their role and understand where they take ownership. Prepare your people and your partners that larger ecosystem of stakeholders that we talked about. Don't let the first time you're engaging with them, be in the middle of the incident. And then to close it out, the post-incident analysis, after the incident, making sure that you're learning from your mistakes, and then also using those lessons, learn to look ahead to address the ever-evolving landscape in front of us.
Great. Thanks for joining us today, Josh, and giving us a really good overview on incident response.
Thank you, John. I really appreciate you having me and thanks for your time.
Have a good day, everyone.
