Ashish Rajan: [00:00:00] You switch off something, suddenly you realize everyone in the company hates you.

Samuel Burgos López: You cannot go and tell them that, "Hey I'm going to start auto-remediation everything." An infinite backlog of low and mediums that nobody fixed. If you have 50 accounts, probably you are going to have 500 issues.

Andoni Alonso Fernández: If you fix it one time, you will fix it forever.

Without these rules, there is no company.

Samuel Burgos López: We are not going to replace this whole process by an AI agent. We need something that is going to be determinist.

Ashish Rajan: Auto-remediation is one of those words that people dreaded in cloud security for a long time. But Anthony and Samuel decided to just take on that problem head on, and have been able to come up with a solution or at least an approach that can help us tackle auto-remediation for the thousands of vulnerabilities we see in our CSPM or CNAPP, and perhaps find a balance of prevention and auto-remediation somewhere in between.

I had a great conversation with Samuel and Anthony, who have been in the DevSecOps and cloud security space for a long time, and we spoke about their approach to auto-remediation, how [00:01:00] do you apply that in an organization, and how do you scale it out. Can AI actually help in scaling this or be a part of this?

And what are some of the things that they would not do if they were to restart this auto-remediation exercise, especially with organizations that they've worked for has done a lot of M&As, so that comes with its own complexity, so we go into that as well. If you are someone who has been looking into auto-remediation or someone in your team or your organization is trying to tackle thousands of vulnerabilities from your CSPM or CNAPP at scale with auto-remediation, then this is the episode for you.

As always, if you have been watching or listening an episode of the podcast for a while, I would really appreciate if you take a quick second, hit the follow/subscribe button, whichever podcast platform you listen or watch this on. We are on Apple, Spotify, YouTube, and LinkedIn, and everywhere you consume your podcast from.

I hope you enjoy this episode, and I'll talk to you soon. Peace. Hello, welcome to another episode of "Cloud Security Podcast." I've got Samuel and Anthony with me. Hey, man. Thanks for coming on the show.

Samuel Burgos López: Hey. Hello. Welcome.

Ashish Rajan: Maybe to [00:02:00] kick things off, I'm sure people would have seen you guys on the Cloud Security conference ecosystem quite a bit, and through the work you guys do with the unicrons.cloud website.

So maybe to kick things off, Samuel, if you wanna give a brief intro about your professional background, and then maybe Anthony yourself after. Yeah, sure. So I started working as a network security engineer at a large retail company here in Spain. In Spain. And I was troubleshooting on-premise issues, mainly related with firewalls and WAF.

Samuel Burgos López: Then that company started building its cloud environment, and I got involved into that project. And that experience was the... I-it opened the door for me to join the cloud security world. And that was when I met Anthony, because we were working to together in the same company.

Andoni Alonso Fernández: Yeah. Yeah, in my case, I started like in more like classic sysadmin, like Linux stuff. Then I discovered Docker, Ansible, and all that thing called [00:03:00] DevOps. Yeah. And I was starting to look for that movement, and then I found Flywire. That is where I met Samuel there, and I moved into more an SRE role.

And then as I always like to look to break things, that led me to the security side of the things, because you have to break things, you need to know them. So at the end, I did an inside move in the company, and I moved to the same team as Samuel in the cloud security team. And then I've been like, I moved to Brawler.

I've been there for a year and a half, like being the maintainer of the tool, like leading the detection and remediation team. And then I end up in CrossMint where I am now with a more like generalistic security role, and I'm doing like DevSecOps engineering. So I- ... now I'm in charge in all the whole SDLC, so it's fun.

Ashish Rajan: Awesome. So today's topic is you guys clearly have a breadth of knowledge in this as well. I was gonna start with auto remediation, which is like the crux of what we wanna talk about. Most people shy away from auto remediation. Most people, and I'm sure you and I, all of us, all three of us have been in this space for a while too.[00:04:00]

Remember that very short time period when there was a auto remediation as a capability that the CSPM kind of came up with, and it suddenly disappeared within I wanna say at least in three months or four months. It did not even last a year, and we will fast forward it really quickly onto the CNAPP and everything else that came after.

So maybe to set some context, why is auto remediation a thing, and why did you guys focus on it? Whoever wants to go first.

Andoni Alonso Fernández: Yeah, I can- Yes ... I can go.

Ashish Rajan: Go for it.

Andoni Alonso Fernández: Auto remediation is, it's hard. Like per definition, it's hard because to fix a lot of things, you need a lot of context. And I think the problem with tools like CSPM is like most of the time they don't have the context because context is very specific to the company, to how the team works and everything.

So I think they released the things that were easy to fix, enable encryption and things like they don't have public buckets. But it's hard to keep going into more deep things because you need a lot of exceptions, you need a lot of [00:05:00] communication with the teams, and it's hard of- because how companies usually are organized, that security is a thing and the teams are another thing, and you need to coordinate.

I think that's why it was hard. And in our case, we had to go in there because we were a very small team. Like we were like three guys in the team. Yeah. And we, our company acquired like several companies. So-

Ashish Rajan: Oh.

Andoni Alonso Fernández: From the, from, in, in a short, very short period of time, our like, our users, let's say, grew a lot, and were coming from different backgrounds.

So we have like different environments with different ways of developing, and then we have to secure all the same way. That's we had to go like for auto remediation, because if not, we had like to double the team in capacity.

Samuel Burgos López: Our environment also is really regulated. We need to comply with a lot of external regulations, PCI, SOC 2, HIPAA.

So at the end, there were a lot of checks that we [00:06:00] needed to pass. Some of them maybe they were useless, but you need to have the check like, "Hey, all my default EBS volumes are going to be encrypted." And maybe you are using not default ones, you are forcing that your new volumes are going to have a key, but you need to have the check enabled.

So what was happening that we were forgetting to enable some settings in new accounts when SRE team was creating new accounts, or when we acquired a new company we were focused on production mainly, and what was happening with the rest of accounts, nobody knows. Maybe I was fixing those accounts manually.

What happened if AWS or DCP release a new or adds a new region? That region was... Nobody was checking that. So we didn't have enough people to handle everything, and we were handling the same remediation in a different ways. [00:07:00] So maybe Andoni was using a script, I was using another one. Maybe another coworker coworker was using the UI.

So-, the auto remediation helps us a lot to standardize everything and do the same things for the entire team.

Ashish Rajan: So auto remediation became that way to standardize across the organization. 'Cause to your point, with a small team, you're trying to scale yourself to scale security, but you can either...

when you can't scale yourself, the only other thing you can scale is like the controls you have and do auto remediation. Now what was interesting about this talk for me specifically... Oh, actually, I should mention that you guys gave a talk at fwd:cloudsec EU on this very topic. I'll put the link in the show notes as well, so people can actually go refer to that talk.

What was interesting for me was that auto remediation is one of those topics where it's a bit, let's say sensitive, because you switch off something, suddenly you realize everyone in the company hates you, and you're like it was ag- it..." You may be doing the right thing because [00:08:00] it's it's you're complying to the policy, but everyone else is "Why would you do that?

Why would you run it for me? Why-- I don't like this auto remediation." Did, did you guys-- How did you guys, A, go about thinking about doing auto remediation, and what was the thought process? Or maybe we'll start there.

Samuel Burgos López: Yeah it is a hard topic to talk with the rest of the team.

So for example with SRE, you cannot go and tell them that, "Hey I'm going to start auto remediation everything." They are going to kill you probably. This comes from a really good architecture and knowledge and information about the environment. Our main environment was AWS, so what we had was to have as an entire AWS organization just for running tests.

This started also with the CSPM. We needed to discover and we needed to add controls, and we were running everything on a test environment. That environment was was isolated and was just for our team. So we got a lot of experience about how to [00:09:00] scale, how to run, how to deploy things in the whole organization without affecting the rest of the teams.

And once we got that knowledge and that experience, then I think it's also worth to mention that you need to build a good relationship with them. You need to trust them. They need to trust you. If not, this is not going to work. And trying to do all the things as engineering process was was doing their releases.

If they are doing everything as code, if they have tests, if they ensure that everything works first in a staging environment, why are you not going to do the same? So we were doing the same. All the things that we were doing were following a pipeline, running tests execute first in a staging environment, and then when we are we were ready for that we released the production.

Also this process has a lot of observali- os- observability to it, notifications, documentation. [00:10:00] Let them know that we are going to start touching things. Let them know what's going to happen if something is automated. How can they stop that for being in a loop? We don't want to be awake at 4:00 p.m.

because they are trying just to publish a packet and our tool is constantly closing the packet. Yeah. So i- it's a really big process. It's not something that you can do from one, one to another day

Andoni Alonso Fernández: Yeah. I think that the key part is the trust part because I, I-- me switching from being in SRE to security, I already knew those pains like, okay, I don't trust these things security is doing because they don't have the context.

So one thing that we did, it was as we were doing everything as code because we didn't want to do click ops like you try to lead by example being in security. As we did everything as code, we could check with the SRE team like, "Okay, we are going to do this remediation this way. Can you double-check that is everything okay?"

So you could-- It was an easy way to collaborate and involve them in the process, so they will [00:11:00] trust what you are doing. Because if you have a tool that they don't know yeah, this is going to fix things, but they don't know how that work, they are not going to trust you. It's like, okay, I need to know how that work.

And also the notifications like, okay, the tool did this and you notify them so they know what's happening in the middle of an incident. You are not a black box, like they don't have access

Ashish Rajan: Do you find 'cause to what you guys said, right? It's it's interesting to scale this across organizations to what you guys were saying earlier about M&As happening, other companies are coming in.

What becomes that... 'Cause there's no relationship there. They're basically-- Someone is basically leading the charge, going, "Hey, this is how we will move forward." At least the M&As that I have done or been part of, I somehow find that they always land on the one person or, sorry, one company is in charge and they set the direction for it.

Sometimes you are the other person, you're not the person who's d- who's the director of it. So it's a bit of interesting dynamics. But I'm curious, does having multi-cloud, 'cause one of the reasons I brought the [00:12:00] M&A topic is that it's not just we're only looking at AWS or we're only looking at GCP, and they come with their own sets of rules and regulations that they have been following for a while, and everyone's trying to comply to what that would look like.

What was your thinking between, say, does it work better on one cloud over the other, or is it the same problem, or that you just have to tackle with people first, and the technology part is still the easy part for auto remediation? Maybe Anthony, if you wanna start this time.

Andoni Alonso Fernández: Yeah. It's totally what you say.

It's people first and the technology is the easy part. Because we were using an open source tool that supports we were using a SteamPipe, so that supports like a lot of clouds. And then that wasn't a limitation. The limitation was going to a team that, for example, didn't had any regulation before and now are part of a fintech and they have regulation.

So you need to teach them like, "Okay, this work this way because you need to be compliant with this because of this." And most of the time, if you explain to them, they will understand okay, this is the rules. Without these rules, there is [00:13:00] no company. There is no company, I'm fired. Yeah. So th- that was, like, one of the things we did, and we were lucky to do it that way, is like for some of those M&A processes, we went in person to the offices of the companies, and that way the relationship was much easier because you will e-speak with them in person, you will understand their process, you will explain like, "Okay, let's do it this way."

You will find the exception, and then you will go grab some beers and solve any issues that might be during the day.

Samuel Burgos López: Oh, it's totally what Anthony said. Being talking with the people that is going to be affected by these changes that you need to enforce it builds the relationship and the trust that you need with them.

You can't tell-- you can, but you shouldn't tell them that, "Hey, you need to fix this because I need to compliance with whatever." Yeah ... explain them all the context. What's going to happen? What's going to change? Why you are telling them to do that? And- Help them to find a way that they've seen [00:14:00] their systems are going to still work in the same way as they are doing right now.

Don't share the problem with them and pass the problem to them like, "Hey, you need to fix this. This is going to break your application. Good luck with that." No. Let's help them, as we are engineers and we have some knowledge about the architecture that they have. Let's work with them to fix the problem and solve everything that we need to solve.

Andoni Alonso Fernández: Yeah. We usually introduce ourselves like, okay, we are the security guys, but we are not the security guys that say no. We are the security guys that say yes, but. It's like that was an important part.

Ashish Rajan: Yeah. We could make that the the topic of the episode as well. Yes, but. Like auto remediation, yes, but.

We could totally do that. Sure. But you did speak about, I think the almost like a three-rule set that you guys thought of or like a rules... not like a rule, but almost like a three princ-principles, I'd rather use that word, where this is how you approach auto remediation. Could you expand on that?

And what was the [00:15:00] thinking? Actually, maybe before we go into this, I know we spoke about the people part for AWS and GCP. Technically, was it difficult or was it easier in one than one cloud than the other between AWS and GCP or Azure? I don't know what kind of cloud you're working with.

Samuel Burgos López: Three of them.

All three of them. Perfect. But almost all our infrastructure is in AWS. So it was easier one than another. Maybe AWS has more tools, more services- Okay ... that work by default and are going to give you a lot of information. But the, the problem with those services is that they are only going to work with AWS.

So if you want to do something in GCP, maybe they have the similar service, maybe not. That's why we changed our solutions. We were using all the default services that all major cloud providers has. But we changed to a solution, SteamPipe in this case, that will give us access and [00:16:00] visibility to everything.

So our deployment was based on AWS, but it has access to any cloud, so the checks, the controls and the remediations are working in the same way for any cloud.

Andoni Alonso Fernández: If it has an API that we can use, it just works.

Ashish Rajan: Okay. 'Cause I think I remember seeing the demo that you guys had.

You had basically Slack notifications coming in into the... so Ashin, could you explain, like with maybe with one example, take whichever AWS or GCP to highlight the auto remediation? Like I know you guys have your own repository for the AWS root manager I think it's called on your repo. Is, was that one of the- Yeah

examples as well for auto remediation?

Samuel Burgos López: You can implement that tool into the remedi- into the auto remediation process. But the, that tool is just like the final solution. It's also a CLI, so it wasn't thought for be auto remediated. It's more like a human interface to be aware of what you have.

Okay. But taking the root [00:17:00] access as example, you have your control in your CSPM with Honq. That control is being injected into Security Hub, but you can use another things, and our automation flow is going to wait for that new finding being added into a queue, in this case a SQS queue.

And then our application, which runs in Lambda, is going to process the event extract the provider- ... in this case, for example, a AWS, assume a role to the right account. The root access is being handled at the A- AWS management account. And then it's going to execute the control using the AWS SDK for deleting the root access key.

In this process, there are four guardrails, as far as I remember. So we have the configuration, so we are not going to remediate everything. First the control must be added into a configuration. You need to enable the [00:18:00] control, and you can add exceptions per account, per provider, or per resource.

Then we have a log which was designing to avoid infinite loops and avoid issues in production. So if you remediate something, we are going to add a log during X hours. In our case was 24, I think. And if something happens aga- again, if you run the control again and you get the same fi- the same finding, the auto remediation is going to be a stop because it's the way that we want to prevent something really bad happening in production at a scale.

Ashish Rajan: Right

Samuel Burgos López: And the last one three three guardrails, not four it's the, the bypass. The configuration and the lock are managed by the cloud security team, but the bypass was designed to let the rest of the teams the ability to manage them. So you can add some tags to the resource, for example, a bucket, and if you add a specific tag, the team knows what the tag should be, then the automation is going to be [00:19:00] skipped.

So- and so- ... you have an external way of managing this ...

Ashish Rajan: so configuration locking, bypass, but those three can be applicable across any cloud provider 'cause it's a framework both of you came up with.

Andoni Alonso Fernández: Yeah. Yeah, it's a way it's a way, like we said before, like the, to build the trust. Like you have the configuration, so if you have things that the team know that they cannot fix, see that need specific needs, something that they are going to fix in one month and it's like, "Please give me the time," you have the configuration, they can request like in a scheduled manner okay, this thing is going to be like not applied.

Yeah. You have the lock to avoid like loops, like in the middle of a fire, they need to make a back- up a, a public bucket or opening a security group. They can do it. It will fix one time, then it will be locked. They have 24 hours to do whatever they need, and then at the 24 hours, you will fix it again, and they will need to provide a different reason to move this thing from the lock to the configuration.

And the most important one is the [00:20:00] bypass one. That was like the key, one of the key things that make this successful because it gave the team the confidence, like, okay, if something happens, they... this guy's messed up with a control and is going to break my flow or whatever, I have the bypass. They can use it. They know later they will need to justify why they bypass it, so they don't abuse the system. But they are, like, sure okay, if I need to, I can bypass it. And that confidence, it was like, made people be like, okay, we solved the process and not trying to stop it. Because they knew they have a way to keep with the thing in case we messed up.

Ashish Rajan: H- so what does the decision flow look like? 'Cause I'm almost thinking that this, most organizations have two problems. One is, it, like there's obviously the growing problem of, hey, I wanna have prevention controls so this stops happening in the future. Then the other part is hey, I have this backlog of, I don't know, my CSPM has shown me 10,000 alerts and I'm trying to go through that.

Do you feel like the auto remediation kind of is [00:21:00] more focused on that second pillar where it's more like I have a pool or is-- I feel like it's almost doing both, but you guys can correct me. Is like, is that the balance of the two is auto remediation?

Samuel Burgos López: It's doing both. I think we try to sell the tool as we are going to fix a lot of issues that we are getting from the CSPM.

But on the other hand, it's true that we wanted to also have a preset of settings that we are going to enforce across all our accounts, projects, whatever. And at the end, you just need to run your control and auto remediate whatever you want. It doesn't need to be a security issue. It will be like, hey, I always need to have a role in your account.

You build a control to check if there is a role. If there isn't, you will create it. So it's like mix of things that we wanted to automate. And I think it's also important to, to say that we didn't try to [00:22:00] rem-remediate high or critical severity issues. Or more than high or critical because it depends on your architecture.

The complex one. So we wanted to remove all the things that we are not adding more value to them. We are just executing one thing and all the times we are going to execute the same or we are clicking always the same button. Those things, n- we are not adding value there. Let's remove from our work workday, let's automate them, and let's expend time thinking about how to remediate things that are complex and cannot be automated by default or the AI is not going to work with this by default.

Andoni Alonso Fernández: Yeah. Because usually the, the high-end critical ones sometime need more like research to see how to fix it with the team, and you have a backlog, like a, an infinite backlog of low and mediums that nobody fix because you are focused on the criticals and [00:23:00] highs. But sometime those can be a problem, too.

So if you find some of those that can be solved the same way for everyone- ... if you fix it one time, you will fix it for forever. It's like this, this removes this problem. Like for example, having a, encryption enabled in EBS. Yeah. You solve it once and you forget about it. It's not going to happen again.

Ashish Rajan: Yeah. Yeah. And I guess to your point that's how maybe you're able to almost have a preventative control as well without even wanting to have... It's a si- it's like a side effect of having this auto remediation thing, which, or almost a feature, for lack of a better word. But do you find that and I'm glad you mentioned AI, Samuel.

It's like this is my next question. Obviously you guys have done this already scaling it whether- is gets... How do you how do you approach scaling this across an organization, especially when you have different companies that are being pulled into it as well? What was-- And obviously we spoke about the relationship not being there in the beginning or like what if people who hear this or watch this [00:24:00] and ask, "Okay, what's a good starting point?

I have 10,000 CSPM alerts. Sounds like a great idea that if I do auto remediation I'm almost enabling prevention as a side effect." What do you guys recommend as a starting point to even approach this problem? 'Cause it would feel like a mountain to look at. 'Cause day to day every cloud security engineer is just like open CSPM, go through, I don't know, 100, 200 alerts.

AI or no AI, you're still looking at 100, 200 alerts every day. It... This could be an interesting approach, but to even validate with your managers and otherwise what's your recommendation for how should people approach auto remediation?

Andoni Alonso Fernández: Yeah. This, this one is hard because we don't want to say something and then people will come like, "I break my company because you said this."

But- Yeah. Fair ...

Ashish Rajan: I will,

Andoni Alonso Fernández: yeah, I will start with the, the things that you are like almost sure because you never are 100% sure, but you are almost sure it's not going to break anything, and it's not going to have like [00:25:00] a, a pushback. Like for example, going back again to the enable encryption, like in most of the services that's used like a, a Boolean that you need to put that through and it's going, it's not going to break a- anything.

There is other services that maybe will recreate your database, so be careful with that. But you can take services that is just enable that default or at least put in, for example, the default in all the accounts you have. Like at least new stuff is going to be created in a secure manner.

So for example, you can put the remediation rule only for new stuff. So okay, new security groups can be open to the internet, and this way you protect all the new resources. You don't allow co- misconfigurations to be put in place, but you are not breaking what already exists. And then you can go and check those one by one.

Okay, can I start closing this? So this way maybe doesn't solve directly the problem of, okay, I already have 1,000 alerts in the CSPM, but you make it easier to don't go to 2,000 alerts in the CSPM.

Samuel Burgos López: Yeah. On the other side, I think it's important to have a really [00:26:00] good architecture of the system that you are going to handle.

I don't care if it's for visibility or for remediation, but you can't go jumping between accounts, between projects, between clouds. You are going to lose your-- the, the context you are going to forget about things. Put all your things, controls, remediat- remediations into a single place.

And then the bad thing about this is that you need to build the connectivity between that central piece, which could be a third-party solution or could be a Lambda or an application, whatever with the rest of your accounts, clouds, et cetera. And that's it's a critical point because you are going to give access to an application to do some specific things that could be dangerous to your whole infrastructure.

So please do it in a secure way. Don't give this tool root access if you only need to change the permissions of a bucket. It's a critical point, but it will allow you to [00:27:00] scale to anything. You won't have a issue anymore.

Ashish Rajan: So y- and you can stage your scaling as well. So you could start with one team and scale it out to other teams and one, maybe one AWS account, but expand it to 10, 20, 100, 200, whatever accounts as well.

But I guess your point, you probably wanna pick the right place to start where it's a lot more friendly people than, hey, I don't know, the most critical application of the, of your organization. Maybe don't start there,

Samuel Burgos López: no. Start with a development environment. Start with a test account.

Build your SIEM organization. Start playing with it, and once you are comfortable scale it up.

Andoni Alonso Fernández: And also one thing that this is already a pattern that people know, that you can find your security champions. If you find some, say, developer or something that is very security aware, you can offer "Okay, d- do you want to try this?"

Because people like to try new things. So you can take advantage of that curiosity and it's like, "Okay, do you want to be te- beta tester of this new service? You will reduce the [00:28:00] number of security findings that we send to you because they will fix automatically." And for sure they will be like, "Oh, sure.

That's interesting. No more security tickets." Yes. And they will be like, "Okay, I... let's try this." And you involve them in the process that is al- is always nice.

Ashish Rajan: W- I m- I should have asked since the beginning. So the solution that you guys made, is that available for people or is it just more of a... I know you guys have the demo during the talk.

Is this gonna be like a Unikron start cloud thing?

Andoni Alonso Fernández: It will be. It's something we have pending because we've been busy, but our idea is it's not we are going to open source it, but not so people can just copy and deploy it. It's not going to be like a product. We have it in mind to publish it more like a blueprint that people can follow.

"Okay, we did it this way. This is a bit of the process we followed with some recommendations on how to start, some auto-remediations as example." But as we say at the beginning, this depends a lot on how your company work, how your- ... infrastructure is built. So we can only provide like an, an example, like something that you can [00:29:00] use as inspiration.

And the good thing is now with AI, it will be very easy "Oh, take this repo, check my infrastructure, how I can put this together and work in my context." So yeah. Yeah. But yeah, we are planning-

Ashish Rajan: May not be a bad idea. I was also gonna say to what you were referring to as well, with the with the repo being available for people to start.

But perhaps a good starting point could also be what their CSPM is already showing, could that be a good starting point as well? 'Cause that... To what you said earlier, I think there could be a pattern you may see that, hey, yes, you could hi- work on high and critical, but there's a EBS volume encryption required as a low, medium.

You could just go, "Oh, my CSPM seems to have, I don't know, 20,000 of these. If I do that, hopefully that reduces from, I don't know, 50,000 to 30,000 or whatever." That could be a good starting point as well. Y- would you agree?

Samuel Burgos López: Yes, and I think that's what we did. Trying to remove all the, the small things that were important, but we ha- we had hundreds of [00:30:00] them.

And it's usually popular in AWS a lot, having a lot of settings per account, per region. So if you have 50 accounts, probably you are going to have 500 issues. Yes. So just remediating this is going to remove a lot of i- findings from you.

Ashish Rajan: Interesting. Cool. So maybe as a closing thought on this as well then now that we have spoken about h- what your approach was and how you thought about this and where to start with this particular ecosystem as well in terms of the friendlies and having one cloud rather than just doing everything together.

W- if you were to redo this start from today, for lack of better word, would AI play a role here? I'm just curious if it would play a... And if it would, what kind of role are we talking in terms of making it... Would it make it quicker or would it just make it easier? What would the, what would that look like?

Samuel Burgos López: The system probably is going to be the same as the one that we have right now. But it's true that we used the AI to build the system at the beginning mostly [00:31:00] the software as we come from different worlds. I'm not a software engineer, so I wasn't-- I wanted the peace of mind to have my application running in production at scale.

Yeah. And that's why we use the, the AI. But it's true that we are not going to replace the, this whole solution, this whole process by an AI agent. We need something that is going to be determinist. But it's also true that right now with AI, you can have some skills. So you don't need to know maybe the code where we did the, the application.

We are going just have a skill that is going to create the controls for you. So it will give us a faster deployment from scratch to production that without AI probably will take months.

Andoni Alonso Fernández: Yeah. It gives you the ability to solve things that maybe it will take you more time because maybe you are not familiar with that part.

For example, we are, like, very familiar with AWS, but less with GCP. So [00:32:00] having AI allow us okay, I know that this will be fixed almost the same way as AWS, but I don't know how this API works. AI helps there a lot because you can build a script that you know that you can review it, but maybe you cannot write it because you don't know that SDK from top of mind.

Yeah. So you can review it later and say "Okay, this works," and as we already had all the testing harness for it, you can test it and you are, like, sure that you are not deploying something that is going to break. So it will- ... speed up. It's been speeding up things a lot for that.

Ashish Rajan: So the key driver to scale this would be the testing harness that you would build.

That- Yeah ... 'cause then you can just run it on AWS, GCP, I don't know, Oracle, Azure, whichever one you want.

Samuel Burgos López: Everything, yeah. Yeah. But you will be sure that it's going to work because you are going to test it in a almost real environment, but without breaking your component.

Ashish Rajan: So your testing harness would have your policy as a general policy defined, and then it can use that as to what you were saying, Samuel, earlier.

Then based on the provider, [00:33:00] it could just make a call for, oh, based on my AWS provider, the policy says EBS volume encryption, S3 bucket not public, all of that as a policy for that. And so you update that as a way to scale your AWS as well, instead of rewriting the code every single time.

Samuel Burgos López: Yeah. Yeah, but your testing environment should be exactly as your production environment.

So we have the same structure, the same process, the same architect to deploy two times.

Ashish Rajan: Yeah.

Samuel Burgos López: So we are going to run exactly the same in the test environment.

Ashish Rajan: Okay. That makes sense as well. I, I don't know, Anthony, do you wanna add anything else to that testing harness piece for people to start building it?

Andoni Alonso Fernández: Oh, I think the thing when you are developing things related with infrastructure in opposite to when you are just doing, like, software development, is like- With software, like you can trust a bit more the tests. If you write a test that is testing that A plus B is C, it's going to be this way.

But then when infrastructure is not always the same, I think all the people in [00:34:00] infrastructure have some suffered sometimes with Terraform, like saying that the plan was going to do a thing and then when you hit apply, it does a different thing. So that's why the testing harness is important because I don't feel the same trust in infra testing, like as code than the real testing of the infrastructure like things.

Because it's like, it's not always matching like one-to-one what they say they are going to do what-- with what they do.

Ashish Rajan: Yeah. Fair. And I guess your point is someone has manually changed it versus if you may have used a template, but Ashish decided to log in into production and change something because, I don't know, I was fixing a bug or whatever.

You don't know what that would look like. Yeah. It's a fair point, man. Yeah. So those are-- those are all the technical questions I had for you guys. I have three fun questions for you guys. And we can... This is like a rapid fire, so whatever first comes to your mind, so first one is maybe Anthony, we'll start with you.

What's what do you spend most time on when you're not trying to solve the auto remediation problems of the world?

Andoni Alonso Fernández: Oh, that's a good one. Lately it's been running. [00:35:00] Like I- Oh ... I like to do a lot of sport, and it's like last year was paddle, and this year it's been running. I'm preparing a half marathon for this Sunday.

Nice. So-

Ashish Rajan: This Sunday?

Andoni Alonso Fernández: Yeah. Yeah, this Sunday.

Ashish Rajan: Oh, man. Car- carb loading for the weekend I imagine then.

Andoni Alonso Fernández: Yeah. Yeah, I will start today. But yeah, I think that is the thing that I do, like when I'm not preparing, like working or preparing more talks, because these last two years have been busy, like preparing all the community events that we've been.

Ashish Rajan: Fair. Samuel, what about you then?

Samuel Burgos López: Probably I spend my most of my free time going for walks with my dog. I have a- Oh ... a huge dog. But also in the sports world. In fact, I did a, a hyrox last week. Oh, wow. It was the first time.

Ashish Rajan: How was it?

Samuel Burgos López: It was hard, but, ... it's fun. It's really fun. Being in the, in all the environment with all the people, it's- Yeah

it's really fun to do it. Did

Ashish Rajan: you do a solo or did you pair with someone?

Samuel Burgos López: No double. I don't think I can make it [00:36:00] alone.

Ashish Rajan: I don't know if it's any, it gives you anything but couple of years ago, I did a hyrox London solo. It was not an easy... And to make it difficult for myself, my wife called it my midlife crisis.

I did it in a suit as well. I wore a suit and I did it. But there was another guy at the same hyrox. He was in a firefighter outfit with the oxygen cylinder at the back and did the whole thing.

Andoni Alonso Fernández: Whoa. And

Ashish Rajan: I was-

Andoni Alonso Fernández: That's crazy ...

Ashish Rajan: I thought I was finding it difficult. That guy would have found it even more difficult.

That's a good segway to my next question as well. Second question, and maybe I'll start with you, Samuel, that one. What is something that you're proud of that is not on your social media?

Samuel Burgos López: Whoa. That's difficult.

Ashish Rajan: And I'm sometimes think about this.

Samuel Burgos López: Whoa. Probably my music life. I st- when I was young, I started to play piano and percussion and drums, and then I took the decision to go into the technical world and engineering.

But I keep that I keep playing in at home, the piano and music. That's [00:37:00] all. I don't have a group. I'm not playing outside. But I'm really proud of keep doing what that,

Ashish Rajan: Music ...

Samuel Burgos López: was n- yeah.

Ashish Rajan: I look forward to one of your performances at a conference one day, man. Part of the training exercise could be a performance from Samuel while everyone's waiting for their auto remediation to work.

You're just playing a piano in your background. That could be something as well. That could be funny. What about you, Anthony?

Andoni Alonso Fernández: That, that will be fun. We can try that in Spain, so you can bring the piano and do

Ashish Rajan: something. You could definitely go viral on social media if you're like, while everyone's on AI, Samuel is just beautifully playing a piano in the background.

What about you, Anthony? What's your proudest moment just not on social media?

Andoni Alonso Fernández: Yeah. I don't know because I posted the run, the running thing a few times, so I can I rule out that one. One, one thing I've been doing like lately that I'm proud of it for myself is I've been helping or mentoring a few of past colleagues that, Oh, wow

I had that are young, and I've been trying like to help them as I would love and some help- people helped me like when I was like [00:38:00] young in this career. I've been trying to help them like find a better job, how to continue with their career, giving- ... just my experience so they can have another point of view.

I'm trying to help them with that, and it's very rewarding. It's like seeing people being happy when you help them with that. They like, It's very like a grateful thing to, to-

Ashish Rajan: It's very fulfilling as well. You get to see them kind of- Yeah ... go through, grow their journey, and you've, you've-- and to your point, it's not just giving back to the community, but also feels good as well to, to be able to help someone and basically show them the path 'cause you've already walked the path and maybe fallen a few times as well before.

Andoni Alonso Fernández: Yeah. See, yeah, it's especially that. It's like I'm not giving you like a perfect blueprint. It's just I'm telling my mistakes and what I think I did right, so you can just- Yeah ... have another point of view that can help you apart from all the community thing, like we do.

Because one thing is going to out and give a talk. I like to do that. It's very rewarding, like teaching people things. But when you do that one-to-one, it's a [00:39:00] different thing. It's like you feel more responsibility, but at the same time it's like very rewarding.

Ashish Rajan: Yeah. I think so. So final question for you as well then.

What's your favorite cuisine or restaurant that you can share with us, Anthony?

Andoni Alonso Fernández: Oh, that's also a hard one because- I don't know if Samuel is like, "Oh my God." Yeah. That's a hard one because I like to eat too much.

Ashish Rajan: What's the first one that comes to mind? You're just stranded on an island, this is the only food you can have.

Andoni Alonso Fernández: Oh, probably Italian then. I

Samuel Burgos López: think we

Andoni Alonso Fernández: can answer- Yeah.

Samuel Burgos López: Andoni, think about this. Maybe we can answer the same one, the one in Adelaide. Oh,

Andoni Alonso Fernández: yeah. We have, I have- I don't remember

Samuel Burgos López: the name.

Andoni Alonso Fernández: It's The Golden Boy in Adelaide, Australia. Yeah. Oh. That's our favorite restaurant. It's, Why is that

Ashish Rajan: favorite?

I'm curious.

Andoni Alonso Fernández: We were-- one of the M&A process we did was in Adelaide, so we were there, and the first day we were trying to find a place for dinner, and he's "Oh, this one is this has Thailand food. This looks good. Let's go there." And it was amazing, and I think we went over two or three more times- Yeah

while we were there.

Ashish Rajan: Oh,

Andoni Alonso Fernández: wow. And [00:40:00] I love that place. So yeah, I think for me it will be, or Thai food or Italian food because I love pasta.

Ashish Rajan: Oh, yes.

Andoni Alonso Fernández: So one of those two- I mean- ... will be my favorite one.

Ashish Rajan: All, all the running you need all the pasta, man. What about you, Samuel?

Andoni Alonso Fernández: Yeah.

Samuel Burgos López: Oh Thailand food maybe it's my favorite one, so that restaurant in Adelaide, it was great. It-- They also have a random menu if you want... you can order there some specific things, but if not they have a menu that they are going to give you some random plates, and they all were amazing. If not I don't know, maybe some local restaurant here in Valencia. I really like the Spanish

Ashish Rajan: food.

Yeah, it's great food anyways, man. I think people from all around the world come to Spain for food, so it's not nothing wrong in that you saying Spanish food's good, yeah. We're like-- we're basically people are traveling to Spain and America to find, or even Mexico for that matter, to find good Spanish food.

So you're in a good place, man, so I'm not surprised that you actually love the local cuisine as well. I was gonna [00:41:00] say both, since both of you like Thai food, is you know how they have the really spicy levels as well? I-- And as an Indian person as well- Yeah ... I cannot tolerate the spice.

The Thai spice is way too high. How are you with the spice levels for Thai?

Andoni Alonso Fernández: Between

Samuel Burgos López: low and medium, I would say.

Andoni Alonso Fernández: I think I'm okay for being Spanish because I went there and I stayed with a, a Thai family, and they were, like, watching when I was eating, like, how much I supported, and they were, like, giving me approvals.

"Yeah, you are, like, tolerate spicy." But yeah. The problem is it's later it's hard to go out, so that's when it's a problem. Yeah.

Ashish Rajan: Fair. Yeah. I-- That Thai spice is very... I guess for people who would probably watch this f- I don't know. But then I'm sure they'll let us know in the comments, what their favorite is, if Thai level spice is good for them.

But that was all the questions I had. I really appreciate you guys coming over as well. Where can people connect with you guys and learn more about the auto remediation talk or the work that you guys have been doing? Obviously, I'm gonna put the unicrons.cloud but can [00:42:00] people connect with you guys on LinkedIn?

Andoni Alonso Fernández: Yeah, sure. First of all, thanks for having us. It's always a pleasure, like, talking with you and being in a podcast that I watch almost all the episodes when I can. And yeah, when... So one thing is the website, we have the unicrons.cloud, and I think the other place is LinkedIn.

I've been, like, posting there lately and I just stopped following other places, like, when people started to move from X to Blue Sky and everything. I just stay on LinkedIn. It was easier to keep up. Yeah. What about you, Samuel? LinkedIn is more for you?

Samuel Burgos López: LinkedIn, I think it's the only social media network that I'm using right now.

Ashish Rajan: Oh,

Samuel Burgos López: fair. So yeah.

Ashish Rajan: All right. Awesome. I'll put those and the link to your talks in the show notes as well. But thank you so much for coming on the show. Okay.

Samuel Burgos López: Thank you. Thank you. Happy to be here.

Ashish Rajan: Thanks, everyone. Thank you. Thank you for listening or watching this episode of "Cloud Security Podcast."

This was brought to you by techriot.io. If you are enjoying episodes on cloud security, you can find more episodes like these on cloudsecuritypodcast.tv, our website, or on social media platforms like YouTube, LinkedIn, [00:43:00] and Apple, Spotify. In case you are interested in learning about AI security as well, do check out our sister podcast called "AI Security Podcast," which is available on YouTube, LinkedIn, Spotify, Apple as well, where we talk to other CISOs and practitioners about what's the latest in the world of AI security.

Finally, if you are after a newsletter that just gives you top news and insight from all the experts we talk to at "Cloud Security Podcast," you can check that out on cloudsecuritynewsletter.com. I'll see you next episode.

Peace.

‍