Adrian Asher: [00:00:00] Yeah, so first of all, you mentioned legacy, and I always say, people complain about legacy. So today, you're complaining about legacy that somebody wrote yesterday. So what are you doing differently today that you're stopping tomorrow's legacy? So otherwise all you're doing is building new legacy so they can have good ideas and challenges.

Maybe they think there's another way of doing it. That's great. That enriches you. That makes things better. I don't like to just be the person talking in the room because I'm not learning. I always want to learn. I want developers to learn from me, but I want to learn from the developers as well and the other architects and all the other teams that make up the team.

Ashish Rajan: If you're doing millions of transactions and are in a regulated environment, and you think cloud native may not be the right solution for you, then this conversation may be the one that you may want to listen to. I had the great pleasure of talking to Adrian Asher, who's the CISO of Checkout. com here in the UK, and we spoke about how they moved over from being a monolith to being microservices.

And now, after all these years, moving from microservices onto being more cloud native using Lambdas. This is obviously an AWS focus conversation, but clearly [00:01:00] it can be extended to other clouds as well. We spoke about how they are using Lambda as a way to reduce overall costs, increase performance, and include security in the overall conversation.

All that and a lot more in this conversation with Adrian Asher, and I hope you enjoy this conversation from our AWS Summit London 2024. And as always, if you know someone else who's probably in a regulated environment and thinking about how they can overcome some of the cloud native world as they move from microservices to cloud native and maybe what applications are better suited to move rather than some of the legacies that may have been left behind.

This is the conversation for you and I hope you share it with other peers and friends of yours who may be working on the same topic as well. As always, if you're here for the second or third time, I would really appreciate if you're on YouTube, definitely hit subscribe alternatively, if you're on iTunes or Spotify, definitely give us a follow. That means a lot as we grow and to the next phase of Cloud Security Podcast. Thank you for all the support. I hope you enjoyed this episode and I'll see you at the next episode.

Welcome to another episode of Cloud Security Podcast. Today I have Adrian. Welcome to the show, Adrian.

Adrian Asher: Thank you Ashish. Nice to meet you.

Ashish Rajan: Nice [00:02:00] to meet you as well. Maybe, to set the scene, can we get a bit about yourself, what's your background and a bit about Checkout as well?

Adrian Asher: I'm Adrian Asher, I'm a CISO and also a Cloud Architect at Checkout. com. I've been working in cyber security, information security for 25 years now, so a long time. I'm a technologist, I just happen to specialize in security. I've run security for banks, stock exchanges, startups and Checkout. com, I've been at for three years is an online payment processor, payment provider. So we process billions of transactions for our merchants who then obviously have their customers.

So whether it's from ordering food online, whether it's for grocery delivery doing money transfers, like these are the sorts of things that our merchants are doing and processing those payments via our systems.

Ashish Rajan: Sounds like you guys are regulated body as well. So there's a lot of regulation.

Adrian Asher: Yes.

Ashish Rajan: Before we started recording, we were talking about cloud native versus cloud naive.

Could you explain what Cloud Naive is and why Cloud Native is better?

Adrian Asher: Everyone talks about Cloud Native, but I coined the expression Cloud Naive to talk about when [00:03:00] you're using the cloud wrong. A lot of people were moving from on premise to the cloud and they were doing that by taking a virtual server from on premise and moving it to a virtual server in the cloud, so doing very IaaS type focuses.

This to me is not the right way to use the cloud. The cloud is more secure, but the cloud is only more secure when you use it so when you're not having to manage infrastructure like patching servers, say an EC2 in Amazon, like if you're doing that, you're wasting your time. You should be using cloud native technologies, so platform as a service, things like Amazon Fargate, things like Amazon Lambda, so that you can actually focus on what differentiates you in the marketplace at the application layer and not what doesn't differentiate you in the marketplace like patching a server for a Linux vulnerability. So trying not to use the cloud in a naive way. So don't be using lots of IaaS type focuses, but really using the cloud platforms as they were built and intended to be is what I define as cloud native.

Ashish Rajan: I would love to hear about the cloud native journey that you guys went through being a regulated [00:04:00] company, there is obviously a, and I can call it a myth or a misnomer in the industry that being a regulated body does stop me from being cloud native.

That's why I'm always cloud naive. Keen to know a bit about your journey as well at Checkout, how'd you guys go with the whole Fargate and Lambda journey?

Adrian Asher: Yeah. So I don't see why being a regulated entity as we are a regulator would have an issue with you using cloud native and the regulators we work with a very supportive of using the cloud in the right way.

But they want us to be managing the environment, making sure it's locked down, least privilege. But we want that as well. I always say that if you actually do the right thing by your merchants or customers, by your internal staff, by your shareholders, then regulation drops out of that. So we want to protect data because it's the right thing to do.

It has value and we want to protect that as a critical business asset, but our regulators want us to protect that as well. That's completely aligned. So by using cloud native solutions like Amazon Fargate or Lambda means we don't have to patch the underlying infrastructure. So when a Linux vulnerability comes out, Amazon is going to take care of that [00:05:00] for us.

If we're using, for instance, in Lambda, if we're using some of the Amazon provided runtime. So for us, we really just need to think about how do we focus on our application code and make sure that's secure. So what is our development process? How do we put security as far to the left as possible? Those are the sorts of things that our regulators are really interested in, is how are we continuing to have security throughout the entire software development life cycle, and not just how are we patching a server, which is the conversation you'd have to have if you're using IaaS

Ashish Rajan: To your point. And the reason maybe perhaps myth is also because of the challenges that people are probably taking screenshots of the last time they did the patches and everything, but clearly because they're managing infrastructure, would you be able to explain on what is Fargate and what is Lambda because they might people, they might be people in the

Adrian Asher: Fargate is a managed platform that allows your container or your application code to run on top of the underlying OS that Amazon provides and manages for you. So as opposed to having to have your own, let's say, virtual server that you've installed Linux or Windows onto. And then on top of that, you're then going to put a container [00:06:00] sort of runtime environment like Kubernetes. They manage all that for you.

So those layers are being taken care of for you. So they get patched, you can choose obviously when maintenance windows and things like that happen. But the great thing about having ephemeral compute, so having this underlying, there's obviously servers under there, these underlying servers that sit there and just come and go as you need them means you can burst up and you can burst down as you need to scale to your customers demand, but also those servers are being continually patched and updated.

So then we know that we're able to ensure that our application code is secure based on the SDLCs sort of pipeline and Amazon's able to ensure that the infrastructure, the underlying OS is being patched. The underlying firmware and the network cards and the servers that sit underneath that they take care of all that for us.

So it's the split accountability model that they talk about split responsibility model. But we really focus on the application and they really focus on the underlying infrastructure.

Ashish Rajan: Sure, you would have heard that there are too many Lambdas, too many containers, a lot of that phrase as well. What are some of the challenges?

Adrian Asher: There aren't [00:07:00] enough lambdas.

Ashish Rajan: You're at the opposite camp.

Adrian Asher: Yeah, so the great thing about lambdas is you should be decomponentizing and we went through a sort of evolution from going from monolithic sort of central software development through to microservices and I think lambdas are even beyond what you would even think of as a microservice.

So you could just have a very specific function if you will being triggered in that one specific Lambda. The key thing with Lambda for me is it's really about an asynchronous design pattern. So as opposed to synchronous communication when a client is talking to a service and waiting on a response, with Lambdas you should really be focusing on how can you do that in an asynchronous way, especially if you're doing batch processing and things at the back end.

So for instance, if we're processing payments, some of them have to happen in real time, but some of them don't need to happen in real time. We could actually put those to an asynchronous pattern. But it doesn't have to just be about payments if you want to scale to billions and millions of transactions even a second Yeah, you can only do that through an asynchronous model and using cloud native techniques to do that [00:08:00] in at least the most efficient way. So I think there should be more lambdas because I think you can scale effectively up and down using lambdas You can really work on how do you provision your compute whether you use reserve concurrency to ensure that it's always there sitting, running, waiting for you. So there's no sort of spin up times. Or do you just want to ensure that capacity is there should you need it? In which case you reserve it, but you don't provision it. So lambdas, yeah, I don't think there's too many. I think there's not enough.

And from a security perspective, because everything I just described is actually more from an architectural perspective, from a security perspective now, each individual Lambda should have its own individual AWS IAM role. Now that role should be the least permissions that individual piece of code needs in order to run.

Back in the day when we had monolithic, obviously we would have roles which would have far too much permissions. Even with microservices, you still have a grouping of things together that make up that single microservice component, all of the role that is applied to that little grouping is still over provision for each individual component within that little [00:09:00] grouping, whereas with Lambda, there should be no grouping.

You have just that individual piece of application logic and the permissions that individual piece of application logic needs to run. Now, that's great from a security perspective because now let's say there's privilege escalation vulnerability in your code. The only thing it can do is whatever that original piece of code was authorized to do as opposed to the entire little micro container or worse still legacy environment monolith.

So that is another benefit from a security perspective for Lambdas. Now, you can obviously with all AWS services, you can run them in VPCs, so you can run run your Lambda in your VPC as well which then means that the data is never leaving your virtual network that you're defining. So then when you're talking to other Amazon services like DynamoDB , which hopefully people are using for a great no SQL sort of data store it's just staying all within your network in effect, not being mixed with anything else and certainly not going out over to the internet

Ashish Rajan: So the role for security kind of evolves to be more working on the application itself, rather than focusing on, hey, to [00:10:00] your point, patching and being cloud naive, you can just basically go into the path of, I'm just looking at the application.

I want to make sure it's logically right. I can get that pentested or whatever else I have to do from a regulatory perspective or making security assurance. Promises, is that where you're

Adrian Asher: Absolutely. The more I can enable my developers to ship code 20, 30, 40, 100 times a day, per individual developer, the happier I will be.

Now, in order to do that, I have to provide guardrails. And it's the very old adage of, why do you have brakes on a car? It's not to stop the car. It's to let you go faster, because if you didn't have the brakes, you wouldn't want to go fast in that car. So it's the same thing with when you're shifting left into your sort of developer cycle.

You really want to make sure you have the tools and controls and the safeguards in place so that developer can run as fast as they want. And they can be pushing that button to deploy to production as many times a day as them and their product manager might want them to do. So how do you do that safely?

You can put in place like a static code analysis tool, so Amazon Code Whisperer. GitHub Advanced Security, Sonocube, these sort of tools actually [00:11:00] allow you to scan your code, even in the IDE before it's even been committed into the source control. Those are the sorts of things you've got to enable your developers to do.

But then you get to the build process, the CI and the CD process. There should be more security that occurs there. Have you over permissioned your AWS IAM roles? So that now you've permissioned every single bucket in your account, but you actually never even use S3. Those are some things where you should look into.

And then maybe even to the point you're in production and you're now trying to do a resource share to a different account that's outside of the AWS organization that contains all of your AWS accounts in. That again would be a bad thing, but you can have service control policies, SCPs, or other guardrails to prevent those sorts of things.

So in every stage of the software development life cycle, there should be some security tool enablement. And I say tool enablement, that can also include the human. Like you've got to provide training, education and awareness. But the more you can make security tooling seamless and invisible the better things are.

If it just works and if it's easier to [00:12:00] do the right thing, Then you don't get developers upset with you when they're waiting on a sign off or when they're waiting on pentest or something like that. If they're able to run these sort of tools themselves that they've been through their own self paced training can go back to it any time.

Then you have happy developers and happy security people.

Ashish Rajan: Is there a cultural change required for? Because I imagine coming from, to your point earlier, the company used to be monolith moved on to microservices now moved on to being more cloud native through that journey. I imagine there's a lot of cultural changes that came in and how code is developed and what is the right place to put security in and all of that as well.

Just to give people a perspective on how different it could look like from, say, a monolith world, because people who may be watching this or listening to this.would be going. Okay, Adrian, sounds like a great idea. If I start doing this, wouldn't I get a lot of resistance from my developers?

What was that education piece? Or how did he get that culture up for people to be A more open to cloud native and more open to being more security first,

Adrian Asher: humans fear change, so through any [00:13:00] transition, you need to manage that change effectively. And this is really about leadership, not just about sort of technology.

So how do you take people on the journey with you, rather than getting to the destination and then enforcing it on people? So you've got to take people on that journey. You've got to help educate them on the tooling that's available, on why it is you're doing it, so they understand the context. So they can have good ideas and challenges, maybe they think there's another way of doing it.

That's great. That enriches you. That makes things better. I don't like to just be the person talking in the room because I'm not learning. I always want to learn. I want developers to learn from me, but I want to learn from the developers as well. And the other architects and all the other teams that make up Checkout.com

so how do you take people on that journey? You communicate effectively, you test things, make sure that they are robust you make sure you have your user personas and you're really approaching things from your user's perspective. So user centric design should happen, not just for the products that we make for our customers, but also for our internal tooling.

A great example of security done wrong is the CAPTCHAs that we all see where you have squiggly [00:14:00] lines or images. Like what we're doing in those is we're penalizing the normal use case. Yeah. So when we come to a website to buy tickets or whatever it is, and we see one of those captures what the company that's doing that is actually doing is moving their security problem onto their users.

I think there's other examples, but that to me is always the best example, is if you wanna prevent automated signups or you wanna prevent other sort of malicious actors interacting with your APIs and your websites. There are other ways of doing it, but instead what a lot of people do is they put these CAPTCHAs in order to ensure that the edge case is prevented, but penalizing all the main use case.

It's the same thing whether you're doing static code analysis. And if you say you have a big scan at the end of your CICD pipeline, and now you're ready to go to deployment and you push the button and security says, no, like that's crazy. At the point you're merging into your main branch, that's the point you should be confirming that all the security checks can be automated and can be done. You should have had architecture design reviews right at the stage before even a single line of code has been written. [00:15:00] Ideally, that's not always practical, but let's see. But as soon as you possibly can, that would be the time to do those design reviews because then security features can be built in rather than added on later.

So the more you can enable your teams to develop, the more on that journey they are with you. It is a journey that you never reach the destination of, and that's fine. And there's always going to be something else coming around the corner. So Gen AI, obviously, has been coming around, but really in the last 18 months, has really taken that sort of adoption curve right up there.

And that's a great example where probably 10 years ago, nobody could have predicted that coming, or at least when it was going to truly impact us. But there's things we could do to prepare for it. So just when we did micro segmentation of our application architectures to make things better so we can swap out individual services and components.

Now, maybe this component has a large language model that's actually going to help it run even more efficiently. If we've decoupled our architectures appropriately, we can leverage that and swap that out without impacting the rest of the system. I [00:16:00] actually think end to end testing is probably a misnomer because our systems are completely chaotic systems now where we have so many different components all at different states at any one time.

How can you truly do an end to end test? You should really do point to point test between the two systems or two services. But if you go back to the Gen AI example here, that was how technology could be ready to embrace that tech, AI.. But your teams also have to be ready to embrace that. And the things I talked about taking people on a journey, if you actually give your team's time to learn these new technologies, to embrace them, to encourage innovation, that's how the human aspects of architecture.

So organizational architecture in this instance, can really prepare for and enable those sort of technologies to come in. There's going to be something else next year in five years and so on. We're on this continual sort of growth curve. That's great. There's always new things to excite sometimes some things do scare from a security perspective, but that's okay, too Yeah, it'd be boring if it didn't but we need to work out how we can embrace them and be ready for them without actually knowing what they are and that you [00:17:00] know that nimbleness both in technology architecture and organizational architecture I think is really good ways of being ready for those when they come

Ashish Rajan: Final question on the whole maturity as well, a lot of people may listen to this or watch this and may want to start somewhere, and I don't imagine it's an easy journey going from monolith to microservices, but then microservices to being cloud native is another I guess curveball at that point in time,

Adrian Asher: One really enables the other. If you're running a microservice, then whether that's their individual component, it's actually a lot easier, even if you want to transition that, say, to a Lambda rather than running on a virtual machine. That's a much smaller step than it would be going from a monolith down to a microservice.

There's people now that are coming into the workforce which have never worked on monoliths. All they've worked on is microservices.

Which is great for them. We've got all the battle scars of having been through that.

Ashish Rajan: Waterfall methodology was a thing. Who knew?

Adrian Asher: Exactly, yeah. So how can we teach cloud native techniques and patterns to this next generation that's now coming in, being developers that are going to be augmented by [00:18:00] Copilot and other sorts of Gen AI based coding augmentation that really helps them be more productive?

Like, how do we do security in that world? Some of the answers are here. Some of the ones we're still developing, but for me, that's what makes it fun.

Ashish Rajan: What would you say could be a good starting point for people who want to go on that journey?

Adrian Asher: Yeah. So first of all, you mentioned legacy and I always say people complain about legacy.

So today you're complaining about legacy that somebody wrote yesterday. So what are you doing differently today that you're stopping tomorrow's legacy? So otherwise, all you're doing is building new legacy. So how are you going to do that differently? There's so much source material you can learn from, whether it's podcasts, other online sort of sources you can learn from, but explore, be innovative, really think outside of the box, experiment these are the things that I still do.

I write code there's not many CISOs I know that have the time to write code. I make that time A because I enjoy it, but B because it keeps me current. So for me, how do you actually understand these new technologies? You have to embrace them. You have to experiment with them. But the question is, you [00:19:00] should do that first, almost like at a thought experiment level, like on a whiteboard, working out where could this fit in?

Not Oh, I've got a shiny piece of new tech. Let's use it. It's let's see if it's actually going to benefit us. What would it replace? What would it augment? And then is actually that the right tool to use?

Ashish Rajan: That was all the questions I had. Where can people find you and connect with you on the internet to talk more about this?

Adrian Asher: If you're a vendor, please don't.

Ashish Rajan: That's good call out. Yeah, what if you're not a vendor, then do you normally hang out on LinkedIn,

Adrian Asher: yeah, I go to various meetups and stuff. There's some good Gen AI sort of meetups around London that are worth going to. Obviously OWASP is, hugely important movement.

I encourage people to be part of that. You can find me at some of these events. Awesome.

Ashish Rajan: So I've got three fun questions as well. First one being what is something that you're proud of that is not on your social media?

Adrian Asher: Okay, I don't have social media, so that's pretty easy.

Just learning, when I learn a new tool or technique when, when I first learned about Amazon Lambda and things like that and really understood serverless properly, I did it in the wrong way. I would write almost like [00:20:00] monolithic scripts that, okay, there are only a hundred lines long compared to a microservice, which might say be a thousand lines long.

But I realized actually there's a lot of common patterns that I was using that I should be abstracting out even in serverless. So then using Amazon Lambda layers, I could actually take a couple of common patterns that I was using out. And then I now have Lambdas that are actually only 10 or 20 lines long, and they're just using my layer, which okay, has 100 lines in still, but it has a lot of the common handling sort of functions that I want to use, whether it's input validation, talking to DynamoDB in a certain way, like these are some of the things. Definitely that's not on the social media that doesn't exist for me. Technology wise that is definitely something I was very proud of learning.

Ashish Rajan: What's keeping you busy outside of doing 9 to 5 I guess?

Adrian Asher: Lately I've been doing MuayThai. Oh really? I've been learning that for the last sort of two years or so.

Ashish Rajan: Nice.

Adrian Asher: So I enjoy doing that and training on that near where I live.

Ashish Rajan: Damn. Last question. What is your favorite cuisine or restaurant that you can share?

Adrian Asher: I love lasagna. So I guess you can call me [00:21:00] Garfield.

Ashish Rajan: Garfield would be it. All right. Thank you so much for coming on the show. I appreciate it.

Thanks very much. Thank you for listening or watching this episode of Cloud Security Podcast. We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast. tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at cloudsecuritypodcast. tv. I'll drop that in the description and the show notes as well so you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.

‍