Transcript
I'm joined with two executives, Pure Storage and Kindral, and I'm very happy that you guys are here. I'm going to let them introduce themselves in a second, but I want to introduce the topic. So you guys are here because you think we're going to talk about regulations and compliance, how to build great compliance teams, how to check the box. Absolutely not. We're not going to talk about any of that. So if you want to leave in the next 20 seconds, feel free to do so, because what we're going to talk about is why those regulations actually exist. What's actually behind them? What are we trying to protect against and how are we thinking about it? We have an explosion of regulations in the United States and around the world, and it's all designed to help companies gain trust with customers, gain trust with governments for the products that they're deploying. And so many people in the industry, in the tech industry and in the compliance world are kind of missing the point. When customers send security questionnaires, yeah, somebody is checking to make sure that you've checked all the boxes, but that's not actually what it's about. So I'm going to let these guys introduce themselves. And when they do it, I'm going to ask that they start with, tell me a horror story that you encountered in your businesses. Don't tell me how you fixed it yet, because we're going to unpack it together. But what happened? And by the end of the session, you'll see why and how compliance was the thing that if you keep it in the back of your mind and you design it with compliance in mind, you can avoid or at least navigate successfully through some of these horror stories. By the way, if anybody has any questions during the process, please have at it. Okay. So I will pass it to you to introduce yourself. Great. Thank you, Danielle. My name is Jivraj Mehta. I lead the strategy for cyber solutions at Pure Storage, been with Pure Storage for over 18 months now. And I'll begin with the horror story. So it was actually six months after I started at Pure Storage and one of our financial services customers, they, and you can consider them as like the model of a customer who follows all the compliance checklists and whatnot. But they got hit with a ransomware attack, right? And essentially over a period of weeks and months, the attackers infiltrated their data, started encrypting it. But when it came at the time that they realized they have been hit and they're sitting in the war room, right? The horror story moment literally came when the compliance person or the individual is saying, hey, we've been compliant. We've done the checks. We've done the checks. But the CISO literally made the comment, those are all meaningless. I can't recover, right? And that's when the entire room basically took notice like, oh my God, we're in trouble. We have not prepared to recover and to recover in a manner that is very, very reliable and very secure. That's our horror story premise. So we're sitting in a war room with a CISO, with the compliance team, with the IT team, and everybody's just looking at each other and trying to figure out what the hell do we do? Scary. So thank you very much for joining us this afternoon. My name is Alan Downs. I have a role in Kindle looking after a domain for our security and resiliency practice, which is solely focused on creating capabilities, methodologies, enabling skills to enable clients to recover. So very much focused on right of the boom events, how a client needs to design, how a client needs to prepare, how a client needs to detect appropriately in order for them to be able to have confidence in their recoverability, particularly around cyber, because it does reinvent the whole mindset about how you do that. But still today, a lot of issues and impacts we work with clients on around the world are human errors and they are natural events. Those haven't gone away, but we're kind of used to recovering from those. The new dimension really is the whole sophistication and pace of change that we see related to the man-made cyber attack designed to cause maximum outage, et cetera, et cetera. When you asked me about the horror story, it's interesting because I've been in IBM associated with this practice for over 30 years now. I know I don't look that old, so it is true, right? And across that kind of time with IBM and now with Kindle, we span from IBM, as Chris has mentioned earlier in another breakout session, what, three years now ago, Emilio? Three, four years ago? We've encountered a lot of impacts that our clients have been through, okay? The one that sticks out in my mind the most is sitting in the boardroom of a tier one bank. I won't even mention the country, but we were sitting in the boardroom of a tier one bank and the topic was in and around how can we have confidence in our ability to report green to the regulator, banking industry. So therefore, they were regulated. Regulation was becoming more stringent, a higher focus, a higher priority, but the discussion was help us understand how we can get to green, okay? So the discussion was focused on the metric, right? It was all about how we can get to green. The representation from the CIO office, who's in charge of data and data backup, compliance, success rates, was very quick to talk about the backup success rate and the number of completed restores and very confidently declared that they could restore in eight hours. That eight hours made its way through to their report, their submission to the regulator. Those of you associated with kind of European regulations will be aware the European Central Bank pushed out a stress test paper and therefore all these banks were asked to respond with the official position signed off by the auditor, your equivalent, I would imagine, in that organization, all determined, right? Job done. The metrics reported, okay, based on how they had been testing and rehearsing on that. Interestingly enough, the trace risk officer was then tasked with go prove it. Somebody outside of the CISO, somebody outside of the CIO office, somebody outside of the infrastructure RISO, remember, data sensor, right? RISO, facilities people. Chief risk officer, go prove it. We were asked to do the proving. Best, most perfect conditions. Actually, it was more like four to five weeks, one of their critical business processes. Most likely outcome, they couldn't. That's one of those moments where you think that I'd bank with this client, my mortgages with this client, these guys, you know, have my savings, okay? And that's probably one of the most striking moments where you sit there and you go, oh, my word, this industry is not prepared. By the way, conservative organization. Historically, very proud of their record of being compliant and adhering to compliant. There was no misdemeanor going on or misleading. Genuine outcome. Proven different approach to explore it. Proved to be unreal. But if you think about the impact of that, very horrifying. I have many more horror stories, but I think that was the one that probably stood out most in my mind, yeah? It's all wow. So I moved my savings account with them. I kept my mortgage there. I kept my mortgage there. Sorry. No, but the point is, is I think you illustrated it so perfectly. You've got a compliance person, I don't know if this actually happened, but coming in and saying, but we're compliant. And she's like, so what? You can't recover and your systems are down and they're not going to come back online in the time period that you wrote down on a piece of paper. So how do we bring this to life? So we're going to unpack these stories and I want to unpack them in three ways. Let's break them out into three different categories. What's really behind compliance? Category one, visibility. Category two, trust and control. Category three, skills. So let's talk about visibility. Who wants to go first? I can go first, yeah. So I think one of the things to keep in mind, right, as you deal with complex infrastructure and even more complex now with AI, right, is you cannot build resiliency for things that you cannot see, right? So visibility is the starting step, is the starting point. And the key to that we at Pure at least have told our customers, our partners, is one of the first steps to visibility is you need to simplify, right? Simplify your infrastructure across your tooling, right? If you have datasets, if you have, you know, networking that's spread across silos and you will then have multiple toolings that's built upon those silos as well, right? And so getting a cohesive view and a comprehensive view across your dataset, right, starts with consolidation, starts with simplification, right? So simplify, that's the first thing, because then it will build a confidence in like what I'm seeing is actually what I'm getting, right? That's the first step. The second step in terms of visibility is actually automation. Like you need automation across your stack so that, you know, you can build out this entire infrastructure that integrates across the various toolings that you have, right? So you need tools, you need infrastructure that has robust APIs available that can integrate across. Last one, and I said this, integration, like you want your storage infrastructure or your compute infrastructure to integrate with your cybersecurity tooling, right, with the likes of Commvault. But then you want that to also be integratable with likes of Kindle, the dashboards and the visibilities that Kindle and your service provider provide. So across that stack, that visibility requires, number one, simplicity, number two, APIs, and number three, very robust integration across those three stacks. So Alan, I want you to layer on top of this with visibility and add in control because in your example, the bank, I highly doubt that bank had homegrown all of its own technology that led to that situation. So how do you deal with the supply chain coming in, control, trust, in addition to the probably lack of visibility that that team had and to what was going on? So just to back away from that for one second, I passionately believe working with a number of clients around the world, the number one challenge they face today and weakness they have today is awareness and visibility, yeah? I really do believe this is a key challenge that they have, and it starts really in terms of a client truly understanding what is their maximum outage of tolerance. Look, there'll be lots of metrics around backups and RTOs and RPOs. The world's changed, right? It's now really looking at making sure there's an awareness across the enterprise of that maximum outage of tolerance and making sure that there's an understanding of visibility into what are the dependencies that exist within the enterprise. We all talk about minimum viable company, right? Most companies will say, I know my minimum viable company. We help them verify that, right? But then understanding the impact of the outage of that minimum viable company is something where clients start to struggle in terms of financial impact, reputational risk impact, regulatory non-compliance impact, and not to mention the trust factor to their users, et cetera, et cetera. So I do feel there's a lack of awareness in terms of, one, what are my critical business processes? What are those critical business services that support those processes? What is the dependency across the enterprise supporting those critical business services? Awareness. What's the dependency at the organization layer? We mentioned skills, right? What's the dependencies at the application layer or group of application layers? What is the dependency across the data layer? Do I know the dependency of a critical business server to my data? Where does it sit? Where does it exist? It may be in AWS. Okay, where? What's the single points of failure? What's the single points of risk of that? So awareness to me has to filter through every single layer of the enterprise. Alan, just pause for one second. How many of you in the room, how many of your companies have written down on a list, or at least talk about it in an executive meeting with the board of directors, here are the five systems in the company that can't go down, or we are offline? How many of you know what those systems are? Can name them. All of you? None of you? Okay, so not many. You're in good company, by the way. Had any of you been brave enough to say, I know, don't worry, I wouldn't have put you on the spot and asked, because the next question would have been, do you know what the spare tire is if they go down? How do you fail over? It's such a great question, and nobody knows how to even begin to answer it. But without that answer, you don't have visibility, and you're answering it at the moment of a crisis. Yeah, and often clients are discovering the dependency at the point of crisis or event that's happened, and by which time it's too late. Hence the big retail in the UK, right? Retailer in the UK. Throw and down. Throw and down. And we're only now five months in. If Derek was here, he would know for sure, but five months, they are out. Okay? Interesting story. A big tier one bank was surprised when they lost one of their critical business services following one of the hyperscaler outages the other week. They didn't even know because it was through the third party supply chain. They did not realize that one of the critical business services had a dependency on a data center sitting in Virginia, okay, that had an impact treated by human error. That's not even a cyber attack. So I know I go on and get quite passionate about it, but I work with so many clients who don't know the answer to the question. Great question. You've just asked. So therefore, in my mind, awareness is critical. Understanding that, understanding the interdependencies, and then understanding what is the maximum outage tolerance that becomes your KPI around which you design the process, you enable the skills, you implement the solution with the right controls to be able to manage that risk. Yeah. Long answer to you. No, it's fantastic. Okay. So let's talk about sort of the third tier, which is skills, which is really important because what we hope is that people leave this conference, and if you're at all in the compliance space, you say, okay, I know what I have to do. I need to go find out which systems are so business critical. And there's not a lot, there's half a dozen at most. And I need to make sure I understand that. And then I have to figure out who's responsible for the plan to have them fail over. What are the skills that are needed to do that successfully? So Diana, I want to answer that, but I want to add on to something that Alan said, especially around control and trust, right? The big challenge, the challenges that Alan laid out, like we see it all over the place, right, especially in terms of awareness, but you cannot build trust if you cannot verify, right? The old adage, right? Trust, but verify. And how do you build this skillset is by ensuring that the systems that, hey, you have visibility into and the dependencies that you have identified, right, just as Alan, as Alan mentioned, is you need to have a process to verify that those plans in a continuous manner, it's building that muscle memory, right? And I go back to the horror story earlier in the conversation is that bank, they did not have that muscle memory built around recoverability. So it goes back to your organization, right? And your people that they need to have this muscle memory built around recoverability, they need. And how do you do that? It's the same way as, you know, you go to a gym, you want to build a muscle, you got to go there every day or, you know, have a consistent mechanism around it. So those processes need to become part of your organization's either, you know, day to day function or a month or a month by month function that I have these systems. We have these identified. We can see where they are, but we need to go through all of our playbooks. We need to have this muscle memory built in to our, you know, IT staff, to our CSO staff, that when something does happen, they know how to respond. Right. And it cannot be that, oh, when when something happens, we're going to fly in people and they're going to help us because that is a recipe of disaster. Because that just takes a long time. It's like, you know, you cannot you cannot make a cake if you have 10 people sitting there just because you have 10 people sitting there. Right. So the skill set you need is actually built into your organization over a period of time. Have the plan on how you go about doing that. But it needs to be girded on the foundation of visibility. I know what I'm doing. I know the dependencies. And then, hey, what am I recovering? What are those mission critical applications that I do need to recover? And then you bake those plans in a consistent manner. I completely agree, and it's interesting at the skills level, I see it in two dimensions. There's the technical skills, who knows how to go and do the discovery and to go and discover the dependency. But you know where I put the emphasis and skills and I think about the skills in our organization, it's it's more to do with a mindset and a culture. All right. It's more to do with that mindset and culture. And that's the shift that has to happen. Right. So I heard Chris Lovejoy in the other session say something that I've made a note of and I like it. We've lived in a world of metrics and one of the problems with regulations, you tend to get this, show me your success rates and show me your compliance to your KPIs, etc., etc. So it's a metrics given kind of focus. Chris was mentioning metrics need to become a mission. Right. And I love that because what that's doing is it's looking at the skill sets that we are dependent upon to run those critical business services, to ensure the trust of our organizations, looking at those skill sets. And it's saying there has to be a transformation that needs to be a different mindset in terms of what we trust, how we trust, how we create trust, how we validate things. And I love this phrase, trust but valid, if I verify. Right. I know that's been around for a long time, but it's never more relevant today than it has been historically, because that piece of skill sets beyond just metrics, technical, you know, ability, certification, etc., we tend to hire on that basis. But there's a big piece of this, which is cultural mindset and attitude. Okay. It should not be seen as a metric. It needs to be a mission. Now, the good thing about a mission, you're motivated to achieve it, the success in the outcome of it. Makes sense? Sorry, Guy, I want to add one thing to Alan's point, right? The mission cannot be, we need to abide by this regulation or abide by this compliance. It needs to be an outcome, right? And what is the outcome, right? You know, you have DORA within EU, you have similar regulations in India and in Australia. Over here, you have health care based regulation. The outcome all of them are trying to drive is resiliency and recoverability, right? So when you go out to your organization and you want to build a mission around this, it cannot be, hey, we need to build a mission around being DORA compliant or being NIST compliant. That does not fly because then that is very siloed. That becomes a mission for maybe your compliance organization, maybe your risk organization. It's also boring. Yes, it's boring, right? It's like, hey, how many metrics am I going to check off? How many reports do I need to generate for my regulator? It needs to be like our mission is being resilient, right, and recovering fast when something bad happens. That's it, right? But I think four or five years ago, the buzzword within IT's organization was efficiency. How do we get more and more efficient, right? By cutting costs, etc. That's not the case anymore, right? It needs to be and it's not even a buzzword. It needs to be built in. How do we get more resilient, right? And that should be the mission, not like I need to be compliant with a particular regulation. You both are sort of concluding on this really important topic that the culture of compliance is changing and needs to change probably faster. We have to, you know, the technical skills are foundational, but we have to take it out of the realm of technical and we need to be translating this to something that matters to people, something that people want to sit in a room and listen to. So I think the best way to change culture is to start with ourselves. So I'm going to ask one final question and then open it up. We only have a few minutes left. What is one lesson you learned the hard way in your career, in this space? And how can others learn from it? It's a good question. Because when you go in front of a board of directors, to your point, we need to be compliant with TORA is boring. But I've been in a situation where this happened and I don't want it to happen again. Here's what I learned and here's what we're going to do about it. I think the one lesson that I've learned the hard way is that if you do not break down silos within your organization and across the teams, that the core teams that you know will be needed whenever something bad happens. And if you don't take action beforehand to break down those silos, recoverability becomes much harder. And those silos are not just the silos amongst people. It's silos that you're across your technology stack as well, your data stacks as well. If you do not take proactive action beforehand to identify the silos and start breaking them down in a way that, hey, you know that when something bad does happen, those silos do not exist. And everybody's going to work together from people to technology to achieve that recoverability. You will be in a very bad place when that situation arises. It's a really interesting question, and, you know, one of the things that has struck me over the years is the importance of trust. The importance and trust in your own organization, the importance of creating trust to your clients, trust in the market, trust with the regulator, you name it, right? Trust is probably one of the most important business factors. With trust, you grow. By the way, if you've got the right level of trust, right, you're not competing on price, right? We're competing on reputation. And where does trust come from? Trust comes, and we've said it before, and thank you for saying it, because it got my mind thinking that the true essence of trust is the trust that you can verify, right? You can verify. It's irresponsible to trust without the ability to verify, right? Many, many organizations have fallen foul of that. So therefore, I look at this to say, you know, how can you verify? You verify, and compliance in a way is like a guideline. It's not really, you know, no disrespect to the compliance. It's fantastic where it's appropriate. It's a guideline. But the ability for an organization to verify will be different, okay? So therefore, awareness is so important. Visibility is so important, right? The ability to verify is dependent on you having the right controls to be able to verify, and I'll say it. I might be showing my age here, but hey, test, test, test, test appropriately. And what I mean by test appropriately, break down the silos that we talked about before, don't test the silo. Test what matters to the client's client. Test what matters to the board of directors. That's why we focus. Yeah, and I should really do that, but the point being there is that the ability to be able to test, which in a way that's appropriate to the organization's success criteria, this is why focusing on minimum viable, focusing on critical business services, start there. And by the way, know what the impact is that you're testing against. Payments is going to cost you in certain cases, billions of dollars a day, right? That's not an exaggeration. Clearing houses, right? Et cetera. That's the exposure we're talking about here. So therefore, you know, the lesson I guess I took away was the need to be able to trust, you can trust, you need to verify. Therefore to verify, you need the controls to be able to do that. You need to be able to test, and then culturally you need the skills. Big believer in those three categories you mentioned earlier. Having the visibility, key. Having the controls, essential. Having the skills is absolutely a priority for organizations to be successfully and mature in this space. There is, I'd say it depends upon your organization, depends upon where you are, right? There's no silver bullet. What Commvault, Pure, and Kindle have done, we've provided a tool, a mechanism, right, that organizations can look at and emulate, and if need be, adopt as well, right? We're coming out, we're setting the standard on how organizations and customers can meet these regulations, but in a manner where we are addressing the technical gap, the gap around skill set, the gap around trust, right? So we're addressing that. We've set a standard. Now, will that meet an organization's need? It depends upon the organization. So, you know, looking for a silver bullet, probably not the right way to approach resiliency and recoverability in the first place, but what we have done is provided an example, right, that, hey, okay, this is an approach that we have verified, we have gone through testing at the technical level, at the skill level, that we feel very comfortable going to our customers and our partners and telling them, you can adopt this, and this will help, you know, you recover whenever a ransomware attack happens, right? So that's what we have done. If it meets an organization's needs, that's a great start, and we'd love to partner with them as well. And just to build on that, I think what's really fascinating about what we've done with Commvault and Pure Storage and Kindle, our starting point was through the lens of the client, what is it we're trying to solve for the client? And we picked a regulation. As it happened, it was DORA. So the three of us sat for, I mean, Emilio, you were there as well, right? So hours, days, months, solving to aligning capability across the skills across the technology, across the storage tech, across the control stack that Commvault brings, and we solved to the regulation that was DORA at that time, as it happens, DORA is replicated in every region around the world in terms of common themes that we see. So what we've designed together is very much based on a client need, and it creates an outcome for a client that we can offer to the client with a very rapid speed and capability that meets a lot of those clients' requirements. Yeah. Regulated or non-regulated. And I think culturally as three organizations, it's worked exceptionally well because as the three organizations work together, it wasn't so much the technology, the feature function, no disrespect, it was really... It's the relationship. That's the output. That's the outcome we're trying to solve to. Yeah. It's a perfect way to end because what I wanted to say on behalf of Commvault is thank you to you both. Thank you to Pure and to Kindrel. You guys are really important partners of ours. We've worked very hard on building relationships together and trust. That doesn't mean that we're perfect. It doesn't mean that our solution is perfect, but it does mean we've got a lot of intelligence to bear in the relationship, in the partnership that we bring together for customers. And we're very grateful for you both. Thank you. Thank you. And thank you for having us. Thank you. Thank you for having us.
