Exploring the World of Incident Response and Detection with Pablo Vidal

Host: Hi, everyone, this is Purusottam, and thanks for tuning in to ScaletoZero podcast. Today's episode is with Pablo Vidal. Pablo is the head of security operations at Rippling, and he covers threat detection, response, cloud, and corporate security at Rippling. He has been focused on kickstarting these functions from ground up, and he's working to create world-class security that fosters psychological safety, empathy, and a unique enthusiasm for problem solving across the organization. Pablo, welcome to the podcast. For our audience, do you want to briefly share about your journey?

Pablo: Yeah, I've been at Rippling for 15 or 16 months now, and it's been a pretty wild ride. Just because when I joined, the team was still being formed. And there's been so many things that we've done, both from a foundational and kind of like cross-team collaboration perspective, but I get the feeling that now we've somewhat like put ourselves in the map, and we are a team that is referenced in many places within Rippling.

So I think that like the future is also pretty bright because of all the things that we've been able to achieve so far and all the visibility that we hit that I don't know I think that it just feels that is going to be kind of like smooth sailing from now on.

Host: Let's hope so. So there are two things that I really liked about your work. One is, like you, in your intro, you are not focusing on like tools or security programs and stuff like that. You are rather talking about empathy and building problem solving throughout the organization. And the second thing is fostering the psychological safety amongst the teams.

And I believe this is one of the core tenets of Google as well, like where they say that psychological safety is one of the important tenets. If you feel safe, you can contribute better. So I really love that from your work.

Pablo: Yeah, I mean, I couldn't agree more. We have a team that has really, really good output. And one of the reasons why I find that output is because they feel strongly of the things that they do, the people that they work with on a day-to-day basis, and also even selflessly, like their own career. Like the things that they are doing know how those things are contributing to their own personal growth.

So...having that environment, I think that it feels unique in a way, but it's really, really important to be able to have a team that, at the end of the day, is that you have a team focused on the long term for both rippling and for themselves.

Host: Yeah, totally agreed. So a follow up question sort of to that is how does it day in your life look like today? Like I asked this question to all of our guests and I get unique answers.

So I'm curious, like what does your day look like?

Pablo: That's a good question and it depends a lot on the day and what is going on at the end of the day. Because of the detection and response team is obviously a team who has a pretty wild difference between day to day from an operational low perspective. There are security incidents that need to be handled and that definitely drives the focus. There are weeks that are a bit more quiet where you can focus on strategic planning.

There are other weeks that you're basically on tactical mode non-stop, which to be honest, it's something that I personally like because during those situations, you've really been put to the test and I really like how my team reacts on those situations. Those are the highlights in a way to me because we didn't take any incidents.

There are always a lot of situations where there is no process for that or maybe we are facing a new threat and how the team is creative and figuring things out, how to contain that incident, mitigate it and basically work with the rest of the organization to do our best work. It's one of the things that I'm the proudest about.

And again, as I said, there are ups and downs. Obviously, you don't have to be dealing with security incidents because you would be burning the people out, but it's also something that you cannot control by day to day it varies a lot depending on the things that we are seeing from the organization.

Host: Make sense. And I can see two benefits out of it also, right? Like when you are hands-on and when you are doing the tactical things, you learn and that again feeds into the strategy, right? Overall, how should you design your security program, incident detection and response program. So it helps you in the improvement of the overall security in the organization.

Pablo: Absolutely. And like that's what we put a lot of emphasis on post-mortem exercises at the end of the day, like even throughout the incident, sometimes that you see on the Slack channels that people are already making notes, hey, we should take this point into consideration for post-mortem and like things that we need to do to do better so we don't forget about it. We discuss it and then think strategically about how are we going to be filling those gaps. So yeah, I couldn't agree more with you.

Host: Hehehe Yeah, that's lovely. So speaking of tactical and dealing with incidents, today we are going to talk about incident detection and response. And also we'll touch on hiring security teams. What are some of the do's and don'ts of it?

So let's get into the incident detection and response. So it is one of the fundamental pillars of cybersecurity. And it's important to understand the concept of it. So that it helps with proactive threat management and incident handling strategies.

So to our audience, can you briefly explain the concept of detection and response?

Pablo: Yeah, yeah, absolutely. So I think that one of the things probably your audience is going to be from product security, cloud security, the text-on-response is going to be a mix-able.

Think of the text-on-response as focusing obviously on the detection side of things. Things have happened. Cloud security, product security are mostly going to be focused on the preventative controls. What can we do to stop something from happening? The Detection and Response is going to focus on how are we going to be detecting and responding after something, an event has occurred?

There is a lot that can be done to increase our detection coverage, to identify more nefarious, like be better at identifying nefarious activity within your systems. And then focusing on that, like containment strategy. What are the things that you can do that you can automate to respond quickly and like just in general, better to those events that are at the end of the day going to happen.

Host: So, follow question to that I'm curious about is, you have been working on detection and response for some time. What excites you about this even today?

Pablo: That's a really good question. To be honest, I haven't been working on detection response for that long. My background is on cloud security and that's one of the reasons why it led me to join Rippling. It's the opportunity to basically get familiar and lead the detection response team.

And I personally love it. For two reasons, you could tell when I was talking about my day to day, I was focusing more on the detection response side because it's the- It can be a bit of a roller coaster, depending on whether we have security incidents or not.

But I really, really like being able to give it a different spin in a way to the detection response team. Because sometimes the detection response teams can be somewhat isolated as a bit of a black box into coming from cloud security. It was difficult sometimes to understand like what the detection response engineer was working on, the visibility that you would get there.

And being able to kind of give that a spin and having a detection and response team that focuses heavily on cross team collaboration, on working out loud, on not being as much of a black box is something that I feel really strongly about. And we are somewhat picking the fruits out of focusing on those areas. So, I don't know, I'm enjoying a lot being part of this team. And again.

Because of my lack of technical understanding, I heavily rely on the team to identify what are our gaps within our program on detection and response, as well as cloud security and corporate security, but mostly on detection engineering.

Host: And I must say that often if you are not from, if you do not have expertise in that particular area but from a different area, you bring in a different perspective, right? You think slightly different than folks who have been doing it for a while. So that helps in getting better at detection and response as well. And as you highlighted, like you can, of course you need to automate but feeding that different perspective can ease out some of these activities.

Pablo: Yeah, yeah, absolutely. But also, always starting with, hey, what I'm going to say could be totally wrong. Certainly that, I think, makes it easier for my team to be able to push back and be like, no, this is how we should do it.

And really let them own the program to a certain extent. I am just going to be the one that is going to be helping them, like, providing as much context as possible, providing different sources, trying to make them think bigger in terms of what the organization needs.

But at the end of the day, from a technical standpoint, they are the ones that are going to be actually identifying and executing on it. So I heavily rely on them to be able to drive those.

Host: OK, so a similar question to that is, you have been working at Rippling and you have been running this team.

What have you noticed?

Where do organizations make mistakes? And what challenges do they face when implementing detection and response capabilities, or programs, rather?

Pablo: That's all? Yeah, I think that that's a really good question. I'll go back to the isolation piece. Being able to have a detection response team that have impact across the organization, but not only when running incidents, but also on the project work that they do. I think that is critical. There are things that we are doing that we're working with support with several teams where they can leverage the engineering efforts that we are putting.

So...the Detection and Response team is not only focused on what are our gaps, it's more even focused on what are the business needs.

So the work that I do can be leveraged in other places across the organization. And we just published a couple of blog posts about, hey, like this is how we build our in-house SIEM. And the focus right now is on how can the rest of the organization start leveraging it. So we are somewhat democratizing.

And I think that is really, really interesting and something that maybe hasn't been explored as much. I mean, the detection and response being another team that is going to be used, leveraged by others across the organization.

Host: And speaking of the same system that you guys built, a lot of folks were like, why would somebody build a same system? There are same systems already in place. But when I went through it, I could see why and why and what made you decide that.

And that's a very different perspective than the industry. So I totally respect that, And one of the things that you really like about the tactics, right?

So my next question is around tactics. Like, there are various steps and techniques that are involved when it comes to detecting any suspicious activity, let's say, happening in organizations infrastructure.

Can you maybe walk us through a typical incident response process, including what steps do you take, what are some of the decision points, and stuff like that?

Pablo: Yeah, yeah, no, absolutely. Actually, I'm just going off a Figma dashboard that one of my teammates put together that is perfect for this question. But it all starts with a security case.

So anybody within the organization can create a security case whenever they detect some suspicious behavior, whenever there is something that is unusual. And that security case is going to be reviewed by the detection response team that is going to run an investigation.

and determine whether that is a security incident or not. And it's after that when the investigation begins and the focus on that area, once we have started a security incident, it's around prioritization.

So what is the severity of that security incident? And from there, we take basically follow a flow chart that says, hey, these are the people that you need to add to the incident if this is, let's say, the most critical incident.

These are the steps that you need to take, that focusing on executive summary and identifying like what is going to be the containment plan and how are you going to be executed on it, as well as adding people from external accounts if you need to. So, but it depends heavily on at the end of the day, the type of incident that you're talking about.

Host: Right. So now you highlighted multiple steps, right? Starting from opening the security case all the way to execution, communication, and all of that. Is there a possibility of using automation or any orchestration tool so that it's less painful for the security engineers because they must be dealing with multiple security incidents, let's say, on a weekly basis, right? So do you see any opportunity for automation or orchestration?

Pablo: Absolutely. If you think about it, security, as I was sharing with you earlier, can be very stressful. And because there is a lot of people that are, not a lot of people, but depending on the severity, there could be a lot of things that are at stake.

And if you have, if you're an incident commander, and there is a lot of people that are asking you hey, what is the summary? Or hey, what is the containment? What is the plan? And on top of all the things that you're already supposed to do as an incident commander, you have to create a Google Drive folder and then create a document. And copy the template from the template, and then copy and paste it on the document. And then you also have to create a Slack channel.

And you have to define who's the incident commander, define the steps. There are so many things that could be manual that need to be automated that you have honestly don't have any real return of investment. So being able to automate all the process, so whoever is the incident commander, whoever is running the investigation, can focus on the things that add value.

So yes, how to pretend it's critical for those situations.

Host: OK, a follow-up question to that is, earlier you highlighted that once you have a security incident or once somebody raises a security incident, you go through prioritization. Now, it's crucial for security professionals to manage the urgency when they are addressing the security issues, right? And at the same time, they have to make sure that they do not compromise on the accuracy as well.

How do you balance the need between rapid response and then doing thorough investigation so that you can minimize false positives?

And at the same time, like you have 50 other things going on, right? So how do you keep that balance between urgency, like rapid response and the accuracy?

Pablo: That's a good question. One of the things that I would say is that having a rubric helps a lot. At the end of the day, eventually you'll have a team that is worldwide, spread across different time zones. And you want to make unbiased decisions whenever a new security case is created or a security incident is ongoing, you need to perform an investigation.

So you want to make sure that regardless of the time zone, regardless of who's handling it, you follow the same process and you follow the same rubric on what is a step 0, what is a step 1, what is a step 2. Being able to tie that and make an unbiased decision on this is the criticality of this incident and it also has its own SLA.

But even same things apply to the way you tackle your own work. So you're going to have projects, you're going to have tactical, ask for operational load, the more context you have, the easier it will be for you to identify what is the best recurrent of investment at each given time.

That associated with SLAs that you have for the instance that you were running a hybrid rubric is really going to help you making good informed decisions on a day-to-day basis.

Host: Right. That's spot on. That makes a lot of sense that unless you have a rubric, you are trying to learn while you are, let's say, addressing a security incident, which can be very difficult and stressful. You're adding more stress to your day-to-day job, which is already stressful.

So earlier, one of the things that you said is, tooling or technology can definitely help when it comes to incident response and detection, incident detection and response.

So since last one and a half years, we all have been like we have been learning and also using generative AI, right? And it has been making quite a bit of impact in our day-to-day lives.

I'm curious, like, what do you see, how do you see it even impact the future of detection and response?

Pablo: That's a really good question. One of the reasons why not only it's already having an impact, but from a balancing perspective, we are building a team. The team has been growing a lot, which means that we are putting a lot of emphasis on foundational things and getting the basics right.

But then on the other hand, you have more risky bets, if you want to call it. If you want to use generative AI.. well, it's difficult to come up with a… tangible outcome. Like you want the team to focus on it, to learn how to leverage it, to again, like reduce operational load for instance, but also it's difficult to quantify what is the outcome of those bets.

So one of the things that for instance, the Pietrocan detection and response team is doing is he's implemented the OCSF schema on the logs that we are ingesting and leveraging generative AI to be able to provide in a sample of logs, basically infer what is the schema that we should adopt for any given log source.

Again, this is just an example. Hopefully, we'll eventually post about it, and how are we doing that. But it's something that is a really good example. Also, the InfraSec team, Shreya Sish, has basically been working for three or four months on how can we leverage generative AI to create our own, let's call them like junior infrasect person that is going to be focused on getting all the information from all the different data sources provide automated answers.

So whenever somebody is posting on a Slack channel asking, hey, how can I manage secrets? So that automated bot is going to automatically report by investing the information that people from Confluence to be like, hey, this is how you can do it. So again, that at the end of the day, lowers operational load on the team.

Host: Yeah, I was going to ask you, like, how do you see security teams using Gen.ai, but you have already answered that, and you already have a bot in place, it looks like. So I have a slightly different question.

Do you see Gen.ai replacing security engineers in the future? Because you have already started, right? You have a bot which is able to answer some of the questions. So how do you see it?

Pablo: Oh. that's a good question. I think so, but I think that it's part of evolving at the end of the day. Think about us being able to remove the tasks that don't add that much value. But they can also be that are repetitive to the team.

One of the questions that I usually ask the team is like, hey, like… What are the things that you like best of your job? What are the things that you'd like the least at the end of the day? And really no one likes dealing with operational load. Oh, I've been seeing this alert over and over and over. I'm not adding really any value.

Those are the type of things that you can use generative AI or any tooling around that to be able to remove those operational tasks, to be able to give them a ticket with an alert that has been enriched with all sorts of data from across your organization, you should identify to be able to deem that as, hey, is this a false positive? Is it not? And so on based also on previous alerts, there is a lot that can be done to remove that operational load.

So I don't see that as a negative as in, or people are going to be losing their jobs, but people will be focused on items that are the highest value. So from an engagement perspective, even there'll be like, hey, my time is always focused on things that really bring the best value that make me do my best work rather than having to focus on repetitive tasks.

Host: Yeah, I totally agree. It would make existing engineers more productive by eliminating some of these repetitive tasks, as you said, and also maybe guiding the engineers in the right direction or providing more context, as you said. If there is a security incident which opens up, if the board can provide context from the entire organization, that makes the life easy for the detection engineer. So yeah, totally.

So now coming to, I just want to pivot slightly. You joined Rippling and you started working on incident detection and response.

For any security enthusiast who wants to get into incident detection and response, what advice would you give them?

Pablo: Again, I want to preface by saying that I haven't been that long in the tech center response, so I'm a bit of a newbie on that. So take what I, with a grain of salt, whatever I'm going to say. But I think that like somewhat similar to when I was on the cloud security side, focused solely on the cloud security side of things. There are a lot of things that you can do even within your home lab that have to are directly related with detection and response.

Like I'll give you an example. I have a bunch of Raspberry Pis that I've been buying since the first version. Like being able to have a home lab where you're going to be pulling telemetry from all those systems, aggregating all the data in a security data lake that can be one of the Raspberry Pi’s, writing detections.

Like there is a lot that goes into how are you going to be ingesting those logs into your data lake? How are you going to be writing detections? Like do you have a pilot for writing those detections?

All those things can be done for, at the end of the day, really cheap within your home environment that will come with a lot of lessons learned about how can you do that at a bigger scale.

I usually give that example, but there are also, if you don't want to do it within your home lab, a lot of, I think, like free opportunities within the clouds themselves to start playing around and building your own locking Justin pipeline or… Data lake, again, like being familiar with all those tools is, is really critical and focused on the, on the building side of things. That's what I would say.

Host: So getting your hands dirty so that you get familiar with the area and you learn from it so that you can use it in your current or future job in a way.

So other than that, any other key qualities or skills that could make someone successful when they transition to detection and response teams?

Pablo: Uh, on the non-technical side, I would say more of a growth mindset. Uh, the field is constantly evolving. Uh, so you'll have to pivot a lot on, and you'll have to basically not, you know, we get defensive about the things that you've done in the past and how they can be done better.

If we were talking about generative AI, that's obviously just one example that is really hype right now, but there are a lot of things that will constantly evolve and being able to adopt that and embrace it, it's really going to help you be on the top at the end of the day.

Host: Ok, I really like that. Now moving from, like, let's say changing fields, it looks like you have an amazing team, right, with you who has been helping you with the overall mission of detection and response.

So now when you are hiring, hiring for the right blend of qualities and skills is very important.

So What are some of the key qualities and skills that organizations should look for, like both from a technical and non-technical perspective?

Pablo: It depends a lot on the organization. Like at Redbling, we use happily AWS. So the skills that I'm going to be looking for, since we want a team that is a security engineering team that is going to be engineering things, building things on AWS, you have to be an expert on like, obviously it's impossible to be an expert on all the everyday services, nobody's, but being able to build things that are critical for detection and response and leverage those tools is a bit of a non-starter.

Because we are also not from a detection and unit perspective, but also from a response perspective. You're going to be responding to alerts on AWS. So being familiar with all those systems is critical for you to be able to handle that operational load and be good at responding to those incidents.

And more on the non-technical side of things, Ripley is a startup. We are growing a lot and that's really exciting. But it also comes with situations where things can be messy at times, chaotic, and we embrace that because it gives us so many opportunities to get things done quickly.

One of the things that I like the most about Rippling is that there are no politics. Given the size of the organization, it's critical that there are no politics involved. So every single person on the team can really drive whatever they feel strongly about. So that strong drive is something that we are definitely looking for.

Somebody that is really willing to make an impact. And that also like feel really empowered on working cross-team, thinking big, thinking, hey, I don't want to only focus on detection and response gaps and what the team needs, but what this rest of the organization is. Like, how can I reach that gap? How can I learn about… what other teams need across the organization and how can detection of response help them out?

Host: Hmm. So getting not just being just focused on your own area, but rather thinking about the whole organization. How does security, how can security help others also? Oh, yeah, that's a very different approach, I would say, because most organizations, what happens is if you are a detection engineer, you're very focused on that. But I see it very different at Rippling.

And one of the things that you said is Rippling is still a startup. I don't know whether I agree to that. But I understand what you mean by that.

Pablo: Yes it is. I mean, look again, I haven't worked at that many places in the past, so it's difficult for me to tell you. Out of the 100 startups that I've worked at, this definitely feels like a startup. But to me, it does because of how quickly we are moving. And you could go on vacation for a week, you come back and you're like, oh my God, I... There's been three products that we've shipped and things are moving so quickly. And I love that.

Host: And often, startups have one of those advantages, the speed, advantage of speed. So I love that Rippling is moving that fast. So now, those are the skills that you look for. Let's say you hired someone, or you're trying to hire someone.

So what strategies would you recommend organizations so that they can attract and even they can retain top security engineers in the organization.

Pablo: Uh, like I think that from attracting talent, uh, one of the things that is critical is around making sure that they have a fit, you can show them your program, uh, but at the end of the day, uh, for them to be able to see themselves doing something or re-playing, they need to know what they are needed for.

If you show them your program and you're like, Oh, we're pretty good. I, yeah, I think that they might not see how they're going to be leveraging the skills that they have into your program. So being able to show them, hey, like, this is where you fit, and this is the, obviously showing them like, this is the people that you'll be working with that will help you find that fit, and like also find the potential impact that they have is critical.

If they don't see that, it's very unlikely for them to be able to feel strongly about replaying or like wanting to join your team. if they don't know exactly what are the things that you're going to be doing. And sometimes it's not on you to tell them, oh, you're going to be focused on that. But sometimes, hey, just being able to tell them, I'm going to heavily lean on you to define your own place here, leaning on the things that you're good at.

Like one of the things that I ask all the people that I interview is, like, what are the things that you can hit the ground running on based on the things that I've shown you? And like, how can we get advantage of that knowledge?

Because it's not, we don't do planning top down. I sound like, hey, you're going to be working on this, this and this. I just shared with you how we try to think big. And if it's just prior decision being back top down, it's too narrow. So I think that having that balance is important.

Host: Okay, so that takes a lot of sense. Now, hiring is difficult as you know, right? Hiring the right team member is difficult. It looks like you have some sort of formula.

So, can you share some like common do's or don'ts while hiring, like during the hiring process or even evaluating a potential security engineer?

Pablo: Yeah. The one that I would focus on is around the mutual fit. I've been on interviews myself as a candidate where it felt one-sided. I was responding in question, but there was no desire to share with me what the organization is doing, where could I fit.

So ensuring that there is a mutual fit and that you lay that out as in, hey, I'm going to show you as much as I can about rippling, and I want you to show me as much as you can about yourself.

So we ensure that it is not overlap. Without that overlap, things are not going anywhere. And I've come across situations where I am not really learning about the company, only the five minutes that I have for questions. So it makes me hesitant. It's just another thing that given the amount of uncertainty that switching jobs have, if I don't really know what I'm going, what I'm getting into you cannot always, depending on your situation, take that leap of faith at the end of the day.

Host: Okay, so the tip that I see here is for hiring managers or leaders who are hiring is that be open to share about, let's say your current situation, your goals, and see if there is a mutual fit with the candidate. And the same I would say for candidates also, right? Try to understand if there is a fit with the organization based on your knowledge, based on your aspirations as well. So a follow up question to… that is like if let's say you are hiring,

What are some red flags or warning signs that you watch out for during the process?

so that you can say, hey, the candidate is not a great fit for our team.

Pablo: The one that I would stand out, that I've seen in a few cases, is one that regardless of your experience, I remember mentioning a few questions ago that you have to have a product mindset. You cannot get defensive about the things that you've built in the past, but it also applies to.

I've had a chance to interview people that have a… 15, 20 years of experience that have been on multiple places, cloud security, detection and response, product security, and have got to a point where they think that they know it all.

So that's a bit of a red flag. When somebody comes across us, oh yeah, like I've been doing all these things and really I'm ready for anything. And that mindset doesn't feel like somebody that would be humble to really join a team, learn about the environment, to be able to evolve with it, to be able to be flexible depending on the situations that you face.

So that's one of the red flags that I've seen that I would really encourage everybody to be like, hey, every company is different. And the practices that you had, like the security team has also evolved.

So the things that we did, like that I personally did eight years ago, were terrible. We're really bad. It shouldn't, like, I think about it continuously as like, four years ago, we've done things so differently. And being able to realize that and identify the things that you have done wrong and be able to get them right the next time, it's something that should happen.

Host: And I must add that it is not just about security, right? Even with engineering or any team, like if you look at what you have done a few years ago, you would be like, what was I doing? But that analysis is what helps you get better so that you can correct those mistakes and get better on a day-to-day basis. So that's a great way to end the security question section.

Summary

Thanks Pablo for the fun conversation. Here are a few important points I gathered:

  • In order to ensure success of security programs, security engineers should not work in Isolation. Instead, they should collaborate across teams and organization.
  • For Incident Detection and Response, organizations should have a rubrik. It reduces the stress on engineers to figure out the right plan of action and next steps.
  • When it comes to hiring the Security Engineers, both Organizations and Candidates should look for Mutual Fit in terms of Skillsets, Future goals and Scope of the work.

So the next section is focused on Rating security practices.

Rating security practices

So the way it works is I will share a security practice and you need to rate them from one to five, five being the best. And you can add context, like why you have given a particular rating. So let's start with the first one.

So the first one is develop and regularly test an incident response plan to help quickly detect, respond to and recover from security incidents.

Pablo: I'll give it a four just because probably if you're starting a program, that's not the first thing that you want to do. You probably want to create a new service response plan first. But I find that we do like quarterly people top exercises here.

One of the things that stand out from doing those exercises is trusting collaboration because it's really fun for the product security team to work with detection response, or cloud security, or Cubsight and think about, what scenario can I come up with, that is going to make it difficult for the team that is on the blue team to respond to that.

And it basically helps getting people together, which is what we want at the end of the day.

Host: Right. I was hoping you will say five, but I understand why you said four.

So the next one is granting users unrestricted access to systems and applications so that they can move fast and roll out new features quickly.

Pablo: I'm going to give it a two on that one. Not a one because I think that the one below is probably worse, so I need to rescribe them.

But obviously a two just because, again, it might be needed at a given time. Again, if you start with five, nobody's getting access to what they need. Probably 10% of startup is not going to grow as it should. But obviously, it's just a kind of worms if you do that regardless of the size of the organization.

Host: Yeah, makes a lot of sense. The last one is DevOps practices are needed to move fast and deploy code to production. Security practices are not the most important right now.

Pablo: Actually, I'm going to give it a two as well on this one, because it feels that depending on the size of the organization, security might not be, shouldn't be prioritized at a given point in time.

I think that it even makes sense when there is only like a SRE team or one person on the infrastructure team, they won't be able to prioritize security practices on the DevOps practices. But obviously, on the long run that is going to bite you back at some point in time.

Host: Yeah, agreed. So that was the last question.

But before I end the episode, do you have any recommendation for our audience? It can be a blog or a book or a podcast or anything.

Pablo: Yeah, something that I read, recommended by our Cesar Trillio, was Mindset. I really like that book. I have two kids, so I personally like that book from many areas, not only specific to work, but also specific to parenting, about how to grow kids or how to make sure that you identify good strategies to mentor others and for yourself even, and what it means to have a growth mindset versus a fixed mindset. So, yeah.

Host: Yeah, Mindset is an amazing book and I agree. Like it just doesn't focus on parenting. It also focuses on how you can grow as an individual also, and you can help others around you. So yeah, that's a great way to end the podcast.

Thank you so much, Pablo, for joining. It was lovely to speak with you and learn about incident detection and response, but I really like more on the hiring part and the culture part. So thank you so much.

Pablo: Thank you for the opportunity.

Host: Absolutely and to our audience thank you so much for watching see you in the next episode. Thank you

Powered by: Cloudanix

Get the latest episodes directly in your inbox