Bola Rotibi:
Welcome to CCS Insight's podcast series. My name is Bola Rotibi and I'm the Chief of Enterprise Research here at CCS Insight and your host for today's discussion on Navigating the Path to Secure Apps. Joining me today from VMware is Darran Rice, Tanzu Value Advisor, EMEA, and Michael Coté, a senior member of the technical staff and a technical evangelist.
I'm also joined by Clive Howard, CTO at Huozhi, a provider of a humanitarian fintech platform. Clive is also an associate practitioner analyst with CCS Insight. Welcome to you all.
Michael Coté:
Yeah, hi there. I'm looking forward to this. Thanks for having me.
Darran Rice:
Hi, everyone. Good to be here.
Clive Howard:
Hi, Bola. Good to be here.
Bola Rotibi:
Excellent, excellent. Well, the year is 2023, and it's well known that security breaches are an ongoing challenge. In recent months, there have been numerous high profile security breaches impacting various industries and organizations worldwide. These breaches can include unauthorized access, data leaks, ransomware attacks and other forms of cyber threats targeting applications and their underlying infrastructure. Data from across CCS Insight's research studies consistently cite IT security as a top priority to address, as well as a top challenge to overcome. When looking at any of the messaging narratives and product updates of new innovation launches, security is front and centre of the core capabilities on offer from many of the software providers.
So, I'd like to ask my first question to you, Darran, given your 24 years of experience writing infrastructure and application modernization within the financial and banking industries. So, securing IT workloads and systems is a constant headline imperative. But why don't organizations get it right?
Darran Rice:
Yeah, it's a great question, but I think there's a few things here. We talk about IT organizations. They're quite large, they've obviously got a lot of history. And so we're talking about a huge amount of technical debt existing in these companies, right. So when we talk about trying to secure systems, we're not just talking about securing modern systems, you've got to secure all your systems right back to your it's your legacy.
It's also a constantly moving landscape: technology is being brought out every day, it's moving so fast and new security vulnerabilities are discovered every day. So it's a constant race between remediating those vulnerabilities and discovering the next one.
So, I think the other thing is when you talk about these large financial organizations, people have this kind of idea that it's either a modern application or it's end-of-life: there's a huge thing in between, which is applications that are happily running in life, but they're not modernized. They're running maybe on VMs or physical machines. And the reality is it's hard to keep those systems secure. You've got to constantly monitor them and patch them, right? So, it's not an easy undertaking. And so, it's all about how much technical data the organization has. And finally comes down to people, because we think so much outsourcing now, if you think about cloud, a lot of cloud is outsourcing. But it's you know, a lot of vulnerabilities are exploited internally, right. Disgruntled staff or whatever it is.
So, a lot of security has to be around the access controls we put around the systems as well as just has it got the latest patch. And obviously, with trusting all your IT systems to other providers like cloud, we've got to be doubly sure that those systems are secure, so we're not even being exploited by our own operators.
Bola Rotibi:
So in other words, actually when you think about the landscape it's vast within organizations and there's so many different vulnerability points, access points from the brand new to the kind of legacy, happily working operations. And then something comes new then you have to review the security challenges or the security profile or the posture all over again.
That's quite a hard task. And that actually, you know, nicely brings in Michael. I mean, you have extensively studied how large organizations get better at building software to run better and grow their business. Where are they going wrong in this in terms of trying to secure their applications?
Michael Coté:
Well, I think, as Darren was saying, right now there's a lot of opportunity to use new technologies to make things better. Right? So in my mind, just to be brief about it, the ideal way of doing software is like you can release your software every week if you want to. So, you can start to experiment and design things and make stuff better, which I always enjoy as a customer. I don't like software that's not better, I guess it would be worse. But I think in doing that and moving at that speed, it introduces some possibilities for just, at the very basics, like developers to get things wrong.
I mean, application developers, they're not security people and often security policy is (as a former application developer) really annoying. Like a lot of it is sort of like doing, you know, I'm being snarky about it, but like it emphasizes doing as little as possible and making sure that you review it, that you're following best practices.
And so, I think nowadays one of the things that I see people getting wrong, if you will, or how they could do better, is thinking about how they can automate more of security and speed it up, almost thinking about security as something that developers are interested in and are happy to use. And I think a lot of that comes down to and this is more general with all large organizations, is that companies don't really have a sense of all the activities that it takes to get a release, to get software out the door.
And until you have a view in that and until you can start going in and automating and fixing and kind of integrating all those activities that happen, I mean, you're always going to have an issue with a, let's say, a governance thing, like security, right? And I think until you build out that, whatever you want to call it, a pipeline or value stream or whatever, you're always going to have problems in, as people like to say, the software supply chain, you know, getting it as they would like you to have a secure software supply chain.
Bola Rotibi:
Yeah, that's a good point. And I think you mentioned that visibility inside of everything and what it takes to get application out. And so actually visibility is something that we constantly talk about and something that we constantly see that organizations do sometimes lack in fact, we often find that it is the bit that, you know, that is missing. So therefore, if you can't see it, how can you secure it?
So, Clive, Michael said some stuff about, "oh, developers don't really kind of like, you know, some of them always do the whole security" and, you know, I think we can all chime with that. But, you know, you have to look at development all the time and in what you're doing when you're faced with making security decisions every day, you know, especially given the nature of the humanitarian financial services platform you oversee.
How does your experience and insights chime with those that Darren and Michael have brought up?
Clive Howard:
I think, you know, there's a lot of a lot of good points. I'll pick up on an area that both touched on which is people and I think it's often neglected in thinking about security because people often think of security as something that is sort of just a systems thing, and as long as there's somebody somewhere checking boxes and configuring things are all good.
But I think two of the biggest challenges are in people. One, which was mentioned earlier, is people as a potential weakness. So, you know, one of the things that we do is we run tests every now and then where we try to kind of trick people as others might do to see, you know, do they put their username and password into something that they shouldn't or share information that they shouldn't or open something that they shouldn't?
I think we see people as one of the biggest security vulnerabilities, both in terms of accidental breaches and deliberate, as again was touched on. And we have the challenge of obviously people operating in very challenging environments remotely, so we have to we have to take that really seriously and making sure that the different people that have access to systems is very much controlled.
So I think people is one thing in that respect and the other aspect as was touched on, you know, taking developers as an example, I think there is one of the areas where I think organizations sometimes struggle is making sure the responsibilities are clearly and correctly allocated because security is distributed across a number of different teams and individuals.
And, you know, you need to make sure that the people understand what their responsibility is and then that they are skilled and empowered to be able to deliver on that. You know, as I think Michael said, you know, there's this idea, well, you know, developers are obviously responsible to a degree with regards to security, whether they like it or not.
But it's one thing to say to them, "okay, you're responsible for this", but then they need to know what that means. What do they have to do? Do they have the knowledge, the skills, the experience, etc., to be able to deliver on their area of responsibility? And then that's clearly, you know, defined against somebody else's area of responsibility, for example, infrastructure, and you don't have things sort of slip through the gaps which can happen where somebody thinks that somebody was dealing with something and they thought someone else is dealing with something. And oh, look, you've got a gap or a hole in the security somewhere. So I think people is a very important area to consider.
Bola Rotibi:
I think people is always the kind of almost the fundamental point to always consider in a lot of things. And you've made some really interesting points. In fact, you actually already touch on the second question that I really wanted to ask, and I want to come back to you, Michael, on this, because, you know, Clive here has talked about the vulnerability of people knowing who's responsibility, who's the most responsible for it, and everyone having the right sort of roles in that place.
So where else do you see all the sort of security pressure points in the IT supply chain? And does this change across industries in your experience?
Michael Coté:
In general, it doesn't change across industries. I mean, you know, just like yourself in the business that I'm in, I talk with a lot of organizations and they all tend to think they're special and they are special in their own ways, but they tend to have the same problems. I think in banking, if you look at the trend to have more open banking, which leads to more APIs and working with third parties, I think that issue might be newer to banking than it is to say retail companies or maybe even logistics and things like that.
So that's, you know, not unique, but it is something specific to banking to worry about. I mean, once you literally open up your business to other people, that's a big deal to worry about. And especially if you trace it all the way back to eventually, you know, going to core systems, which oftentimes involve mainframes and things like that.
Now, we never really complain about mainframe security because I guess it works, which is kind of an interesting thing to consider. However, in general, the things that I think people don't get wrong, to kind of detail what they do get wrong, is I think there is not enough attention put on essentially tracking and ensuring that the components that developers use are basically verified and the authorized ones that you're using.
Right. So, you know, another concept, a phrase that people use to describe the end-to-end process of getting software out the door is like "the golden path", right? And usually, you know, this comes from some Spotify thing. And usually what that means is if we look at what developers are doing and operations people and security people, let's really analyse each activity that's happening and automate it as much as possible and also track as much as possible what to do.
But then equally important, have that be, let's call it a point of intervention to prevent secure things. And I think that introduces a lot of I guess you could call it people-introduced risk. And then the second thing I would go over is I think, you know, people are important. And I think equally important is thinking about how you change the tools that you use according to how you operate and also how you change the way you operate according to the tools are using.
So, for example, you know, even though there's still plenty of actual applications globally to move the thing, things like Kubernetes and to be containerized applications, when you actually are using containerized architectures, you have the ability to very rapidly rebuild all of production. Like several years ago, Wells Fargo talked about the ability to do this. And what that means is if you're aware of that ability, you can kind of change the way you're operating based on the tools you're using to, just as Wells Fargo did say, like, I don't know, maybe every day we're going to rebuild production entirely, which, you know, isn't going to catch bugs that you have.
It makes it faster to deploy patches for security issues that you have. But it definitely gives you, you know, essentially a 24-hour window or if you can do it faster where you can remove malicious stuff and, you know, kind of clean out all the baddies that are in there. So that's the second thing I would pay attention to is like, what tools could we be using based on the architecture of our application to actually have new security powers that we're using instead of just kind of doing the same thing with new tools?
Bola Rotibi:
Okay. So, it's a case of, you know, well, we've already established that people are a pressure point, but it's also maybe rethinking, reimagining the kind of tools that are available now that can really help rethink and sort of address that. I would say it is basically the tools as one thing.
Darran, you talk to a lot of financial industries and you see a lot of things that are going on. What other pressure points do you see to the ones that, you know, so Coté has talked to and you know, I kind of want to add also the second one, if you could also answer, is, you know, what strategies are working when you know, when they identify this, what strategies are working for securing the application delivery in financial industries?
Darran Rice:
So I think one area we've talked about a lot is obviously having secure systems, but what people that maybe haven't worked in these kind of industries don't realize just how much time you spend demonstrating that compliance. Because there's a mandate that regulators will come in and they will say, you've told me you're secure, show me your secure. And there'll be certain compliance. And are you even compliant to your own standards, right?
And I think that's been a constant battle over the years to just because the opposite you have constantly shifting landscapes, as I talked about before. But that's the same in terms of configuration or security or patches or whatever it is, right.
I think Michael touched on containerization, right? As I move onto the point of how do we do things better, you know, if you've got systems that have been historically had Delta change applied to them over many years, it's very difficult to keep re-demonstrating without just constantly re-scanning that environment every day that it's still compliant.
Whereas if you have the concepts of immutability right, which you know you have with containers, you can demonstrate at source that what you're actually putting into production is a trusted and scanned and signed component. So you don't have to then look at your huge production environment and constantly scan and report on it, right. And I think that's probably an area that's helping demonstrate compliance rather than just saying you're compliant, if that makes sense.
Bola Rotibi:
That does make sense. I'd like to bring in Clive back again, actually. You're building out on a platform every day all the time, right? So, you're at the coalface. What strategies are working for securing the apps that you're building and your delivery processes? What's working for you?
Clive Howard:
I think for us it's to try and put as much of the most critical concerns at the core of the platform. So, for example, you know, our platform supports a number of mobile apps. Now the mobile apps, you know there is a responsibility within those to handle good practice with regards to security, but we don't rely on them for anything that is critical.
Neither do we rely on the APIs that they talk to for anything that is critical. So, while we're still applying security at these different levels in the apps, at the API layer and so on, the really critical concerns come at the core of the platform itself. So yeah, I think one of the challenges that you know, you can run into is like with anything when you're, when you're building applications is replication of, of basically the same thing in different places.
And you don't want that when it comes to security, you don't want to have to have a number of different teams or a number of different people really having to worry about the same security problem in a number of different places and then have that in a number of places are maintained differently and so on.
So, I think for us and we know we're quite lucky because our platform is only a few years old, so we don't have some of the challenges that have already been mentioned. But I think, yeah, putting the critical concerns at the core is one strategy that, you know, we've been able to successfully apply to deal with this issue.
Bola Rotibi:
Well, that's really good. And yes, I guess putting the critical side because I hear that all the time so understand what your core pieces are and then thinking about the security aspect, and it does have a sense of planning really, isn't it? There's a security planning, almost like walking way through it and thinking about what, you know, what that might look like, so that's something. Michael, I mean, you speak to a lot of organizations as we've already established. Both what Darran and Clive have talked about: is anything you'd like to add to that? I mean, I'd be curious to see is there any specific strategies that you think you need to say about that.
Michael Coté
Yeah, well, you know, I think one thing that Darran sort of talked about briefly that I think is worth looking in more is considering all of your legacy applications, all of the existing applications that you have and services that you're using, which is again, it's not something that's unique to financial institutions, but it is definitely a lot more of a problem than other places where, you know, and at banks and insurance companies and the like.
You know, these are literally hundreds of years old companies and organized nations that were sometimes some of the first users of software and compute. And so, I think what I see a lot and this is more general, but the way the way it affects security is it just makes security slower to do and more onerous and more inspecting.
And as Darren was saying, it makes it harder to prove your security when you have these older systems where literally you have people retiring and forgetting how things work. You know, that's a problem for making sure things are secure. But then when you have new development teams and you know, whether it's mobile apps or other things coming along, you have to generally put a lot of effort into making sure that, as Clive was saying, you're using it securely.
I think a lot of that comes from I mean, you know, it being old and neglected, which is a great way to run a piece of technology that works perfectly and makes you a lot of money. But the moment that you need to change how you're operating and start doing new things with it, you know, it's time to spend some more time and resources on modernizing and updating it.
And I think in particular, again, banks are beset by a huge amount of legacy software that nowadays I find that they're kind of desperate to not only migrate them to cloud, but actually change these older systems and update them.
Bola Rotibi:
Well, to be honest with you, that's part of the transformation process that everyone's going through, especially talking about digital transformation, it is kind of thinking about how you kind of think and security is part of that transformation as well, which I think is really important. And I think this brings us to our next question, actually.
And so, we understand the vulnerabilities. We understand the challenges. We understand the pressure points and what works and what processes work. Darran, I'd like to just come back to you and talk about some of the tools. How have tools, you know, some of the processes and technologies involved to make IT systems less vulnerable and which roles are best served by them, especially as we kind of now talk about cloud and multicloud environments?
Darran Rice:
Yeah, so I've always been a fan of the paths and sort of opinionated systems, right? Because I think, you know, if developers have — there's been a shift left, right. But I think there's been a shift left without necessarily worrying about some of the roles and responsibilities that come with it, I think Clive touched on it earlier. And I think some of the practices and tools that have been put in place to sort of allow developers the freedom to work on what they should be working on, which is, you know, adding business value through code, right. And then putting in place a sort of templated or, you know, "golden path" is the phrase that's been used before, But a route to production that has been sort of rubber stamped, it is opinionated, you do have to follow that path. But it does mean that if you do it then you have certified pieces of software that you're using. You have templated approaches to how your code hangs together and brings in security modules, etc.
I mean, I've had conversations with developers in the past that said, you know, oh, you know what? Why should I use, you know, the platform that you've engineered? I just want you to give me a Linux VM and I'll do what I want.
And yes, but then I take care of securing it, setting the standards, monitoring it and all those good things. And they say oh no I want that, but I but I want to have the flexibility. And then obviously there needs to be a compromise between the two. So personally, I think, you know, having those guardrails in place that we have many tools that do these kinds of things and not having people download whatever they feel like from the Internet, but having sort of trusted repositories of known sources of good software ultimately means, first of all, the developer doesn't have to do all that and repeated by thousands of developers throughout the organization. But secondly, you know, it's coming from a trusted place, and everyone's got reinventing the wheel. And by reinventing the wheel, introducing vulnerability possibilities.
Bola Rotibi:
That's a good point, actually. I mean, I think one of the things that I often say and from my engineer background, is discipline and repeatability and having that discipline is actually a way to being innovative. And I think that discipline and insecurity, which is actually having an opinionated strategy and approach at least feels the confidence or allows people to have the confidence that they have flexibility to do what they need to do in their solution and that they're always they're always protected. And I think that's really, really important. And I think that's something that is now being instilled. Security baked in is what we always talk about, certainly in the tools and the processes and the technologies that the organizations are bringing in. So that whole security from the ground level, from the foundations all the way through, at all the different levels and all the different action points, that's the kind of like security fabric that everybody wants.
But at the same time, it's something that's either built in the tools or you have to also be aware of it and experience it in your processes. So, people need to be thinking about it. And this is something we've actually talked about a lot in this conversation.
Clive, are there any tools or processes that you actually specifically put in place to address that or to make your systems less vulnerable?
Clive Howard:
Well, we use a lot of cloud as you can imagine, with a relatively new business. And I think the thing about cloud is that on the one hand, it gives you an enormous amount. So, you know, the clouds especially, we're talking about the you know, the major cloud environments give you an enormous amount of security capability and flexibility, I think, to that point.
But you do have to do something to take advantage of it. And I think there's often a danger that people can think that the cloud is secure and that they don't necessarily need to do anything to actually take advantage of it. And that obviously opens them up to risk. And I think, you know, there's many stories like, you know, AWS S3 buckets and things like that which, you know, often highlight that kind of thinking and that kind of problem.
The other side of it is that cloud in all respects just evolves very, very fast and that includes the security capabilities. So if you're using, for example, a particular service, you may start using it and it has certain security capabilities. But six months later, a year later, even less could have additional security capabilities. So, you need to understand the capabilities that are available.
You need to apply them correctly. But then you also need to be mindful that they are going to continue to evolve and you need to, you know, revisit and think, okay, there's now this new capability that I should perhaps take advantage of. So I think cloud is great. On the one hand, we sort of moved away from, you know, some of the things that, you know, was touched on a moment ago, you know, how it was very difficult.
And we all had of take care of everything from the ground up back in the day to not have that situation. But it doesn't mean it's just out of the box, you know? Good to go. And you can just sit back and think, well, it's all in the cloud, therefore everything is great.
Bola Rotibi:
That's a really good point, Clive, actually, because you talk about all the processes that need to be in place and and it's something that Michael mentioned earlier about golden path processes or golden path strategy approach. So, I want to come back to you, Michael, and ask, is there a perfect pathway for delivering secure applications and systems, and what would it look like for the financial services industry?
Michael Coté:
Well, I think, what it starts with is, to be the "it's not the tools, it's the people" person which is always fun, I think one of the things that's important to think about before you start implementing a golden path or a value stream or path to production, whatever you want to call it, is something that that we in the labs groups that we have here at VMware have developed over the past, I don't know, nine or 10 years or so, which is thinking about developers as customers instead of people who receive the services you deliver.
And I know from the days when I was an analyst Bola, we'd spend a lot of time talking about IT service management and itel and all those wonderful things, right? And I think the operations idea, people in operations now understand that if we build the infrastructure, the platforms, the golden paths that people use, we should think about developers as our customers and talk with them and product managers about what we're doing.
And I think we're just now hopefully seeing security people think about that as well. Sure, you need to deliver the service of securing your organization, but it's also a good idea to think about developers is not just a stakeholder, to use that word, but as a customer for what you're doing and study what they're doing and how they're using things.
So I think when you start with that idea of, I don't know, you could call it security as a product, we call it a platform as a product for operations people. You can start to again, start with that end-to- end chain and think about, all right, let's build out the various boxes in that chain that we need.
And I think in general, if you're doing things in a container-based way, there's a pretty understood view of what that chain looks like, right? Like verifying the images that you have that wrap up the libraries and third-party things that you have, storing them in a registry somewhere, having developers build up those images and make sure you pass tests and make sure that they're following the policy that you have.
And then, you know, moving down and down the chain, right. And we've been doing a lot of work in the VMware Tanzu portfolio to basically take advantage of the way containerized applications are built, which really, because of the layering in containers and the way that you separate out the configuration, whether you're running in Cloud Foundry or Kubernetes or whatever, security people get this great chance to not only, as Darran was talking about, inspect, improve the policy that they're doing, but and I wouldn't use this language with developers so much, but they also had the chance to really constrain what developers can do, right. Like, you know, it's a tremendous amount of control you have when you take away the ability for developers to build the software that gets deployed to production. And instead you do that on their behalf, which leads to those scenarios like Wells Fargo had and rebuilding things.
But I think there's a pretty good template to start with for when you want to build out these golden paths. If you have that, let's say security as a product mindset going into it.
Bola Rotibi:
That's a good point actually. And I like that particularly because, I mean, one of the things that's really come through this whole discussion is actually the people side. So, it's really kind of thinking about getting everybody involved, all the right people involved and actually having that communication, that conversation, you know.
But at the same time, even though there's a level of control and discipline, which I said earlier, which from my point of view and past life as an engineer, having that discipline and that repeatability is really important because actually it does give you freedom.
And in fact, even as a developer, I know developers always want to have the freedom to, you know, build the features that they've been asked to. But they also want to feel confident that the environment also protects them and that they're well within the sort of like the boundaries.
And having that conversation allows everybody to kind of like show where the levels of, you know, constraint what they can do things yet bring them up to speed with things that are changing, I think is really important.
Darran, I want to bring this last one to you before I close this conversation. Have you seen changes in the way that people within the financial services industry, you know, have they got sort of specific processes or approaches that are very similar to what Michael has talked about in terms of like a golden path or value stream?
Darran Rice:
So obviously, you know, the industry is huge and people are at various different points. But, you know, certainly the companies that are sort of being the most successful I've seen, you know, where they are adopting that approach that, you know, we just talked about. Making sure that when you're talking about any of these topics, you're not just talking about a platform, obviously we have a good platform, right?
But you're talking about the processes that go around it, the culture and the people that ultimately teach you how to use those platforms in a way that will most benefit you. Things like educating developers in a way to work in a modern way, that is like you say security baked in at the start. I mean, I've seen it myself. I was a customer of Tanzu and obviously I'm now on the other side of the I don't know, either side of the fence, I like to say other half of the handshake. So, you know, I have seen some companies where the difference between, say, just throwing in a system, installing the software and saying get on with it in the way you used to versus working with people like our labs teams that come in and educate people how to run these platforms securely and in a modern way with security baked in, with these opinions and seeing opinions as an advantage, not as a constraint.
So, of course, there's still a long way to go. There's new technology coming along all the time. And it's almost like keeping that culture and ideology while also bringing in new technology like Kubernetes and cloud is a constant challenge, but I've definitely seen it resonate and work. So, you can run many applications at scale, right? Well, if you get it right.
Bola Rotibi:
Okay, I think that's a perfect way to end this conversation. But before we do, I'd like to come back to each one of you very, very quickly. What is the one thing that you'd like the audience to take away? So, Clive, over to you. Just one point.
Clive Howard:
Okay. I'm going to go back to the point that we had earlier, which is people and just making sure that people understand their responsibilities when it comes to security. And that's not just the people in IT but people across the organization and making sure that they understand, making sure that they are equipped, making sure that they're skilled and making sure that they are empowered to do what they have to do contribute to a good secure environment.
Bola Rotibi:
Okay, Michael?
Michael Coté:
Well, I think if you're kind of like an executive considering all of this, it's good to think about the urgency to change, right? Because just like making software better for its own sake, people don't do that. Otherwise they would have. And so, the great thing about security and legacy software is they can kind of go hand-in-hand, be on both sides of the handshake, to kind of create the need to actually do things.
So, if you want to secure things, it's a good excuse to modernize your applications. And when you want to modernize your applications, it's a good excuse to rethink the architectures you use and the tools that you use. So, you know, the higher up people who are making these strategic decisions, I would try to kind of figure out an angle to drag everything in based on the other one.
Bola Rotibi:
Good point. Darran?
Darran Rice:
Yeah, it's similar to what Michael just said, but, you know, not ignoring that technical debt for much longer because people have done it for many years, right. Because you're going to end up, if you focus on only modernizing the small percentage of applications, you're still going to have the overhead of the of the technical debt, of the legacy applications, and it's only going to get harder because there are more and more vulnerabilities discovered, more and more complexity, so do it now.
Bola Rotibi
That's a good point. And I would bring that up, too, because I think neither of you have mentioned about the tools and the infrastructure. I would also add that increasingly, many tools, you know, now do talk about bringing in security from the from the ground up, they are imbued in the products that they give.
But I think at the moment, what's really key is to make sure that you have a plan. You know, it isn't just security for security's sake, but that it fits in both from a kind of people and process side, but also from what you're actually trying to achieve. And that it's not something that's piecemeal, but something that can be an integrated story.
So, I think that sort of brings us to a rather nice little ending. So, I'd like to say thank you to Darran, Michael and Clive for what I think has been a really great conversation, and really insightful as well with lots of great ideas and I very, very much like the takeaway points. So, I'd like to say thank you to our guests and thank you to the audience and make sure you tune into our next CCS Insight podcast. But until then, goodbye until our next discussion.
Michael Coté:
Yeah, it was great to talk with everyone. Thanks for having me.
Darran Rice:
Thank you very much. Hopefully do it again sometime.
Clive Howard:
Thanks Bola, this has been great.
