Security Unfiltered
Security Unfiltered
Indu Keri's Insights on Balancing Security and Innovation
Experience the extraordinary journey of Indu Keri as he traverses the landscape of IT, from her upbringing in India to discovering her passion for computer science. With a choice between becoming a doctor or an engineer, Indu opted for electronics—motivated by her aversion to dissection—and eventually found herself captivated by the world of technology. In this episode, he shares compelling personal stories and underscores the immediate gratification of creating something tangible with technology, drawing parallels to hands-on professions and emphasizing the crucial role of mathematics in tech.
Ever wondered how unconventional thinking can expose hidden vulnerabilities in security systems? Join us as we recount a fascinating anecdote about a simple number-guessing game used during interviews to demonstrate the importance of thinking outside the box. Indu also opens up about her own career decisions, including the pursuit of a PhD and the unexpected transition to management consulting. We discuss evolving cultural attitudes towards higher education and the profound value of betting on oneself, highlighting the skills and insights gained through diverse academic and professional experiences.
Gain invaluable insights into the essential skills and mindset necessary for cybersecurity professionals. Indu emphasizes recognizing the limits of one’s knowledge and collaborating with experts for effective risk management. Discover the challenge of balancing comprehensive security measures with practical approaches, and the critical need for combining prevention with detection and rapid response. Finally, explore the exciting journey of enterprise workloads moving to the public cloud, the complexities of managing hybrid environments, and the pivotal role of software-defined infrastructure in modern digital transformations. This episode promises to equip you with a deeper understanding of the dynamic world of cybersecurity and IT infrastructure.
Follow the Podcast on Social Media!
Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast
Patreon: https://www.patreon.com/SecurityUnfilteredPodcast
YouTube: https://www.youtube.com/@securityunfilteredpodcast
TikTok: Not today China! Not today
How's it going, Indu? It's really great to finally get you on the podcast here. I'm really excited for our conversation today.
Speaker 2:Same here, joe, really nice to meet you. Thank you for taking the time and great to be here.
Speaker 1:Yeah, absolutely. It's great meeting you too. Finally, you know, indu, I start everyone off with telling their background right, how you got into IT, what made you want to go into IT to begin with. And the reason why I do that is because there's a portion of my audience that you know are in a situation where maybe they're trying to figure out what career path they want to go down and they're trying to figure out if IT is right for them or maybe they're already in a career right. They graduated college, they went down a different career path and they're already in a career right. They graduated college, they went down a different career path and they're saying this thing ain't for me. Maybe IT is something that I should get into right.
Speaker 1:And I always feel like hearing you know everyone else's background, really, you know it'll help someone, right? Because someone will hear that background and say, oh, I have a similar background, so if this guy can do it, maybe I can do it too. Similar background so if this guy can do it, maybe I can do it too. You know, and I felt like when I was trying to get into IT myself, hearing that similar story, you know, made it immediately be consumable to me saying, oh okay, maybe this is actually possible. This isn't impossible.
Speaker 2:I hope so. I have sort of a silly reason and a good reason. So I grew up in India and honestly, the only two things that you did when you grew up in India was you either trained to be a doctor or you trained to be an engineer, and so I was terrified of dissection. And so when I was choosing my college major, I had a choice between choosing biology and electronics, and I couldn't dissect a fraud to save my life and so I went to electronics. So that's a silly part of the reason.
Speaker 2:But then, once I started studying computer science, I loved it, and I loved it for a couple different reasons. One is I was good at math, and so I think a lot of computer science I loved it. And I loved it for a couple different reasons. One is I was good at math, and so I think a lot of computer science and technology is just math, right. The other thing that I honestly loved is there is something very rewarding in the technology profession where it doesn't really matter who you are.
Speaker 2:When you learn something, when you learn a new programming language, when you learn a way to build a system, you can even in 2024, you can actually build something tangible on your own and see the immediate gratification. You know, if I was more capable with my hands I might get sort of the. I have a really good friend who's a carpenter and he does things as a hobby right and every time he does something. You know, you see this just enormous sense of satisfaction. And I feel a similar sense of satisfaction in computer science. Like, I still sort of code from time to time. I don't have a lot of time for it, but I love teaching my son a little bit of programming and it's just so much fun to see that and see being able to create something in a short period of time and just see how that, how that manifests itself. So I would say that's the serious reason.
Speaker 1:Yeah, you really went down kind of two different rabbit holes there. You know, when I was in high school, actually, I took an anatomy class because of course in high school you're thinking, alright, I'm going to be a doctor, you know something like that, right, and we dissected a cat and I was able to get through it. That wasn't that bad or anything like that, you know. And then we went to a nearby college here in Chicago and we went to their anatomy course and there's, you know, people there, right, People on the tables and they're dissecting people. And, uh, that was like my first red flag is like I don't know if I can remove the humanity of seeing a person on a table and dissect them. You know, like it's something completely different. And thankfully, you know, early on in my college career, you know, I went down the very stupid path of taking I think it was calculus one, physics and chemistry, all in the same semester.
Speaker 1:I figured I did it in high school. It wasn't that bad in high school, surely. I can do it, you know in college and I mean, I just got destroyed on all fronts and I passed calculus, you know, not because I studied really hard, but because calculus was somehow easy to me and I was able to kind of piece it together, you know, by the final. But it's a really. You know, it's interesting how many people actually go down that path and then so few actually make it through.
Speaker 2:You know what the irony in all of this is, Joe? My dad was a professor of anatomy, so I think this is one of those things where the apple did fall a little bit further from the tree.
Speaker 1:Yeah, yeah, it's. I don't know. I mean, you know, going through that, did you get a greater appreciation potentially for that profession? Because you know, as soon as I, as soon as I failed at it I mean I failed at it like royally right, Like I failed some core classes that I couldn't even do that kind of just prove that you can study. They don't even prove that you could be a doctor. You don't use your chemistry courses when you're a doctor, Right, I just failed at proving that I could study. You know, it was that a little bit like enlightening in some ways.
Speaker 2:I think it was. I, you know, I've thought of it this way. I don't know how true this is. One of the things that is true in computer science and systems is you can almost always trace something down to something that went wrong somewhere right, if you're writing an application, if you're writing a program, if there's a hardware problem, if you're writing an application, if you're writing the program, if there's a hardware problem, if you have a security breach, any of those things, you can almost always trace it down to something tangible that somebody did or did not. And so that's almost a level of complexity that is manageable by a human, I think.
Speaker 2:Whereas if you even look at the body right, I mean, I don't know what it's 2024. Even in 2024, I don't think we really fully understand how all the parts of the body come together, how the systems work together. And then diagnosis is still. I don't know if you ever watched House MD. It was one of my favorite TV shows. Oh yeah, it's very cool. And then Diagnosis is still. I don't know if you ever watched House MD.
Speaker 1:It was one of my favorite TV shows, oh yeah.
Speaker 2:It's very silly and you listen to that and you're like, wow, I mean so much of this is just inspiration and really trying to think outside the box, and I have a huge amount of respect for that. I think we're just so maybe a different way to say it. Right is carbon-based life is, I think, way more complex than silicon-based life, and I chose the easy path anyway.
Speaker 1:Yeah, it's. You know that same sort of thought pattern really benefits security professionals right of thinking outside the box, understanding how different systems work and then piecing it together in ways that make it work for you in that use case. You know, and that's, that's a huge part of what security engineering is. You know, I may not need to know every little finite detail about a database, but I know how SQL works, or I know how Postgres works, right, and I know the different services that I should be looking for, the different ports that it's using, even, and I can piece together, you know, a system that'll work for whatever use case I'm going into. You know, I kind of want to maybe even just backpedal just slightly.
Speaker 1:You know, I saw on LinkedIn I do very light research. I call it I mean, I wouldn't even call it research at this point right Like I go to my guests you know LinkedIn and I look at the education, I look at the experience. I don't write any questions down, I don't even get any questions in mind, right, because it kind of throws off the conversation in my mind, where I'm listening to ask a question rather than listening to respond or listening to understand that. It's a different caliber, I feel, of conversation. And so you got your PhD and I want to talk about the higher degrees. What made you decide to go after that higher degree?
Speaker 1:The higher degree first, the master's you have to get the master's to get the PhD and then secondly for the master's. The reason why I ask is because I actually get this question asked of me a lot. I got my master's and I'm working on my PhD and I'm very open with my audience and I talk about the actual, you know, statistics and everything that I use to decide to go down the PhD route, right, and everything I use for the master's route. So you know what's your, what's your background with that, was it, you know, like a cultural thing, right? Maybe? You know your father obviously probably has his PhD. You know your father obviously probably has his PhD. Did you want to follow along those footsteps of that level of education? Was there something else going on there that you said, hey, a PhD and a master's is what will provide a lot of value for me and my career and my family.
Speaker 2:I'm going to go down that route. Let me answer one point you made about security engineering, and then, if I may, I can answer that. Yeah, of course you know. It's funny what you said about security needing to think outside the box.
Speaker 2:One of the tests I used to give in interviews this was several years ago is I would ask someone, even in an audience, just to guess a number between 0 and 10. And it'd be interesting. Almost always you'd get back an integer. You'd get a number like 4, 5, 7, 9, whatever. Nobody ever says minus 1. Nobody ever says pi, nobody ever says a square root of 2. You should try this test, and here's why it's interesting, right?
Speaker 2:So as developers, as engineers, you almost always write programs to follow a certain set of requirements or a certain set of rules. So, of course, when you think of a number between 0 and 10, you made a whole bunch of implicit assumptions that these are integers, these are numbers between 0 and 10, and you're only going to give an answer that fits in that pattern. But hackers don't think that way. They want to find the limits of the system, they want to find where things break, and so, as a developer, it's actually very useful to build systems that are secure, and to do that with a little bit of negative thinking. And so I always love people who respond with a completely unreasonable answer to these sorts of questions. Like I square root of minus one, that's a great answer, right, because who in their right mind would actually think of that as a number between zero and 10? But if you have built a system, for example, that is used to accepting integer and that has a memory buffer overflow or some such issue, when you give it a non-integer input or a non-reasonable input, boom, all of a sudden you've created a security issue and developers who think that way can actually protect agents that because they don't assume good intent on the part of sort of the users of their system. And that's something that's hard to teach. It's almost something that you have to learn like through a lot of effort. But once you unlock sort of the magic, sort of that magic way of thinking, is actually very, very powerful.
Speaker 2:So you brought that up and so I just I felt like I had to share that anecdote with you. Let me to answer your question, jill, sorry for taking the scenic route for that one. Honestly, I had. I would love to say that I had a plan when I did my PhD, I think. The reality is I was a kid. I mean, I not a kid, but I just finished college. Right, this is what people did and I just did what I was supposed to. My first intelligent, if you will, self-aware career decision actually came at the end of my PhD, where I was interviewing for a faculty position at a whole bunch of different places and I had several sort of great offers and instead of going on and being a professor, I actually joined a management consulting firm McKinsey and Company and that was a big sort of fork in the road. Like you, you think about these important sort of decision points in your life. I would say that was one of the most important decision points.
Speaker 1:Yeah, that is it's, you know it's. It's fascinating that it was almost kind of more of a cultural you know decision for you. And I say that that's interesting because here, you know, like in America, it seems like the culture is shifting to not going to college, you know, just like not not going all together, and it's almost like a lot more people have the mentality of it's not worth it, it's not worth the debt, it's not worth, you know, the time and the effort, which I don't agree with Me personally, you know, I think that there is a lot of value in it if you do it right. When people bring up the you know, the student loans or the debt that you may or may not incur, you know I've always viewed that as an investment into myself. Like, am I willing to bet, you know, this money on myself that I will study, I will get the degree and I will land the job? That's paying two X the amount that it's going to cost for me to get this. I mean, that's the number, that's the equation that you have to do.
Speaker 1:Am I willing to take that bet on myself? You know, I feel like there's a lot of development that happens when you look at it that way, when you actually execute on it from that angle, because now it's like, okay, I have a lot more in this game than just debt. I want to prove it to myself that I should bet on myself. And when you make that bet and you succeed with it, you know you get your bachelors. It's easier for you to go and say I'm going to go learn to code, I'm going to go learn Linux, you know I can do this, I'm going to go learn these other skills, going to go learn Linux, you know I can do this, I'm going to go learn these other skills. It's easier for you to start making those bets and it's just, it's fascinating.
Speaker 2:You know, I feel like I think it's I have to say it's a very personal choice and, in fact, no-transcript. I learned how to write. Writing is actually a very underrated skill. Being able to write, being able to write persuasively, being able to write concisely, is something that I really learned in my PhD. I also learned patience, which sounds obvious when you think about it, right, there are so many dead ends that you run into when you're trying to solve a really hard problem, and it's easy to just say give up hope, right, but when you persist, you actually end up somewhere. So that was huge.
Speaker 2:I also learned a lot about and this don't sound odd I learned how little we know individually, and it taught me a lot of humility. So that is this joke. I'm sure you've heard of it. When you've done a bachelor's, you think you know everything right and the whole universe of knowledge is contained within what you know. And then, when you've done a master's, you think you know a little bit less and the whole universe of knowledge is a little bit more. And when you've done a PhD, you realize that you only know very little and the universe of knowledge is really vast.
Speaker 2:So I think I went through a little bit of that and that has taught me to and that's really come in handy in my professional career to respect other people's expertise, to really be humble in terms of not thinking you have all the answers, and making sure that you seek out people's opinions and viewpoints right, because ultimately those things help you make much better decisions, especially in uncertain environments, and I think that's what cybersecurity is often right uncertain environments, and I think that's what cybersecurity is often right. You have to deal with situations where things are not clear. You have to deal with people who are very, very proficient in their craft but are often not fully aware of the business consequences or other things, and so when you have that perspective that you know you have a lot to learn from others, I think it actually helps you make better decisions.
Speaker 1:Yeah, that is a very valuable piece of advice. You know, there was a situation earlier on in my career when I was working for a credit bureau where, you know, we were running into a very weird upgrade issue of the security solution that we were using at the time, that my team had owned, and we couldn't figure out why this database was not upgrading. You know, and I've worked with databases before this is not my first year, you know, in IT. This is like year five or something like that. Right, like, we just could not figure it out.
Speaker 1:And you know, at the end of the day, I'm not a, I'm not a database admin, not a SQL admin. I, I, you know I can spell SQL, right and I can navigate around. If you tell me, you know what the table is called and stuff like that. But God forbid. You tell me to, you know, like, list the tables or anything like that. You know, like I'm not going to be able to do that without Google. And, uh, you know, it's.
Speaker 1:It's fascinating that you bring that up because in that instance I learned immediately like, oh, maybe I should have someone that's like specialized in SQL. You know, on call ready for these upgrades. You know, because these upgrades are so intense, um, and they really take a lot, of, a lot of dedication from a lot of different people to be able to pull them off. You know, maybe I should have that smi resource there and you know it worked. You know, tenfold right, because I I had that, that subject matter expert, I had that sql admin or that database admin on the call. They were able to figure it out, you know, 10 seconds in, and resolve the issue and the upgrade moved along right, but that was two or three hours of troubleshooting and trying to avoid going to them that we wasted.
Speaker 1:You know when we could have been in the bar by the time. You know that guy, if we would have just engaged him, right, we could have been in the bar two, three hours later. But no, we were there still doing this upgrade because we had just solved the issue. And uh, you know, as as a security professional it's you have to know what you don't know. You know you have to know the extent of your knowledge, like where your knowledge ends and where someone else's knowledge picks up. You know, you have to be very aware of that and you have to be willing to say I don't know what this is, but I do know someone that does know what this is. Let me find out. You know, I feel like that's a critical, critical skill that you have to learn in security.
Speaker 2:You know, joe, I have to say that's very, very insightful and in fact, part of what made security hard is it's really finding the right balance between what is a sufficiently complete level of security versus doing, you know, like, boiling the ocean right. I know I mean somebody said this right Ships are safe in harbor, but that's not what they were built for right.
Speaker 2:And so I think, in everything that we do on a day-to-day basis, you have to accept a certain level of risk, and one of the things that I've noticed is that sometimes security professionals sort of struggle with that right.
Speaker 2:It was interesting when I was the CISO at Intuit.
Speaker 2:There was this one time I mean I would present to the board on a regular basis, and this one time I made the statement it'll give me a billion-dollar budget and I still won't be able to guarantee 100% security, right, right, and that's a very, very uncomfortable place to be right.
Speaker 2:What you can do is to make things really, really hard. What you can do is to make the best use of the resources that you have, but that just slows the adversary down. But that just slows the adversary down, and maybe sometimes they'll get, um, you know, add, and turn away from you, right, um, because that does happen. But part of what made cyber security so hard is, if you have an incredibly determined adversary, there's almost always some way that they can find to get into your systems, right, and so this is where I think prevention is necessary. But detection and rapid response is a must, right, and that's something that every security organization needs to embrace that, in spite of their best efforts, something might get through the system and they really need to be on eternal alert and then be prepared to respond as quickly as possible, and that's as true of ransomware as anything else.
Speaker 1:Yeah, I feel like being a security professional, you have to understand the adversary's mindset and most of the time, most security professionals are not going to go out of their way, are not going to go out of their way, you know, to hack into your company. I would say that A lot of the times they have to be challenged, you know, like you know, I think, of the CISO of MGM right, I think it was MGM where he said we're completely secure, no one's going to be able to hack us. You know I'm paraphrasing, but he did say something like that and he said that in a news interview like a you know an international news agency it might've been an interview with CNN, right, and uh, I mean almost immediately after they were hacked, and not just like a little hacked, like it was like no, we have all of the information that you store that you consider to be safe and secure and private. We have all of that. It's important for us to always keep in mind, because even in my day job, someone tells me I can't do something. Something switches in my head and I don't know what it is. It happens every single time. You're not able to do that and I take that as a challenge. You know this happens every time and, like you know, my current manager, he, he does a fantastic job at managing, you know, because he he was, he's in the military, you know, so he's used to being around people that you know are like just just tell me, just point me in the right direction and tell me what you want accomplished and I'm going to get it done. And don't ask me any questions of how I got it done, because you don't want those details, you want the results. You know, and, like I have, I have that same mentality Right, and so he understands like, hey, don't challenge, don't like phrase things in a challenging way to to Joe, because it will trigger something in Joe and Joe will literally prove you wrong. He'll prove you wrong in ways that you don't want him to and he'll make it public.
Speaker 1:You know, and I think back to when I was working at an investment firm here in Chicago and you know I had, I had just gotten done, you know, really kind of getting ramped up on the environment, right Of our tech stack and everything, and you know we had just put in this brand new multimillion dollar DLP solution that was supposed to solve all of our problems of insider threat and whatnot. And my manager said you know, you're not going to be able to get around this thing. Because we were in a meeting and he was talking about what it does and I said well, are we protecting the data this way? Are we thinking about this? And he said none of that matters. You know we're not vulnerable to that. And he kind of said it in a challenging way, right?
Speaker 1:So after this meeting I went right back to my desk and an hour later I called him over and I said hey, remember, you know, that meeting an hour ago where you said that we couldn't do this right? Well, I just did it. You know, and here's the proof. You know, in in, I guess, in my ignorant head, right, I didn't realize I could get fired in that instant, right, because I broke several policies and, you know, gave them grounds to fire me right then and there. But I I took it as a challenge and I wanted to prove this guy wrong.
Speaker 1:You know, I I don't even remember what spurred right this part of our conversation, but you have to remember who you're dealing with when we're talking about security professionals and hackers. And, like you said, you know you could have a billion dollar budget and you wouldn't be able to guarantee you're 100% protected, and a part of that is the insider threat. Well, how are you, how are you going to get past a determined insider which most of our employees are right, when they're trying to do their day-to-day job, and you make it harder as a security professional? Right, they're going to find ways to do the same things, different ways to make their lives easier, and so it's just. It's a fascinating world in terms of you know, the mindset that we have to have as security individuals, the skill set that we have to have, and it's always evolving, it's always changing. Is that something that you also see at your own level?
Speaker 2:That's a very tough question to answer, joe, especially about how to deal with insider threats. I think you did one of two approaches for this. First of all, I agree with you that if you have a determined adversary, it's actually a very asymmetric game, right? Because in 100 instances you have to keep them at bay 100 times and they have to get in only once. Yes, so to begin with it's a very, very asymmetric situation.
Speaker 2:Now, specifically about insiders, you know, I would say you really have to decide what type of organization you are. You could certainly be an organization where you're incredibly paranoid about your employees and introduce so much friction in normal things, right and compartmentalize and all of that that you reduce the risk of any security issues. You could do that. I suspect that would really take away from the overall employee experience. Right, and the other way to think about this is have I built an organization or do I operate in an organization that has high levels of trust? Maybe because I have values that drive a certain type of behavior and I have built an overall sense of responsibility, not just to oneself in the organization but to the collective organization, and that might sound a little bit old-fashioned, but I've been part of both types of organizations, and I can tell you, as an employee or as a leader, it's a lot better to be part of the second type of organization than the first.
Speaker 2:Now there are certain situations where you can't avoid the first, and so then you do have to take all sorts of precautions. You have to especially, I think, in sort of defense or classified industries. I mean, you have to take incredible precautions in terms of making sure that the data is not compromised. But for most of the work we do on a day-to-day basis with most companies, I think you probably get more mileage if you operate as a ladder, where you build a strong culture where you minimize you can never eliminate but you reduce or minimize the risk of insider bad behavior. So that's what I would say.
Speaker 1:Yeah, I think that's a very valid point. So we've talked for almost 35 minutes here. We haven't talked about your current role, right, or what you're doing now. So you know, can we talk a little bit about you know what company you're at, what your role is, what that looks like. Maybe even a little bit about what your day-to-day looks like.
Speaker 2:Yep, so I'm actually a reformed security professional, in the sense that I don't do security anymore, and I'll tell you. The first thing is I sleep much better at night. I've worked for Nutanix. I run engineering for our largest product, the Nutanix Cloud Infrastructure, which is basically a private cloud platform that you can use to run your applications both on the private or the public cloud. I'm also the general manager for the extension of the Nutanix Cloud platform to the public cloud. So that's what I do.
Speaker 2:But as someone who is responsible for a business and also runs a large engineering organization, I try to have a mindset mainly because of my security experience, where we build security principles into how we build our product at as foundational levels as possible, at as foundational levels as possible, and ultimately, that allows us to serve our customers in a better way. And so I enjoy what I do and I think it's actually a great time to be sort of an engineer. I think that infrastructure in particular because of things like AI, because of a whole bunch of other things, it's enjoying the renaissance Infrastructure goes through these phases where there are times when it's totally boring and there are times when it's incredibly exciting, and I think we're at one of those moments now where it's incredibly exciting and it's really fun to be part of that journey, right?
Speaker 1:now. So what are some things that bring that excitement with infrastructure?
Speaker 2:I'll give you something that's very simple. Even though public clouds have been around for 17 years, my first cloud deployment was in 2007, when I was, of all places, at Oracle, where, you know, harry still used to describe the cloud as women's fashion, but that's a whole different story for a different time. The journey of enterprise workloads to the public cloud is still very, very early. I think less than 10% of enterprise workloads have moved to the public cloud, and that's interesting because there'll be more applications built in the next five years than were in the last 40. And most of that innovation is going to happen in the public cloud.
Speaker 2:And if you try to do that innovation in the public cloud and all of your workloads are on-prem, that's really hard, and so enterprises are in this strange position about how to navigate this journey and to do that without lock-in to a particular provider and without having to have all of that infrastructure be obsolete and have that really be software-defined right. So one of the things that we do that I think is incredibly powerful is, whether it's your storage layer, your compute layer or your networking layer in the infrastructure, we do everything that's software-defined and software-managed and that really drives enterprise agility, speed and security, and that's coming in to be incredibly important as enterprises are modernizing with digital transformation and moving their workloads to the public cloud. So that's what I find exciting, and this is very much a once in a moment. Right Like this, what we're going to see in the next decade probably won't be repeated in terms of workload migration for another 20, 30 years.
Speaker 1:Right, yeah, that makes sense. You know, one of the biggest struggles with, you know, managing your environment in a hybrid environment overall is that you basically have to have two separate tech stacks. You know, you have your on-prem infrastructure tech stack and then you have your cloud tech stack, and they do not. They typically do not play well together. They all claim that they can do both. Pretty much all of them claim that they can do both, but you find out pretty quick that they can't and that they probably shouldn't be claiming that they can do both.
Speaker 1:The products that were built for on-prem. When they almost get lifted and shifted to the cloud to do that same operation in the cloud, they tend to cost the cloud customer a whole lot more money because they're doing it inefficiently. They're not really coded for the cloud, they're not using serverless. You know applications and all these other things, and there's also a pretty good limitation on those things you know they may do. You know, just using AWS, for an example, they may do EC2s but they don't do containers. Or they do containers but they don't do like the Kubernetes native AWS service, right, that deploys containers. That's all automated through that, right. Or they don't do serverless at all, right, but some companies, like the one that I'm at right now, has over 100,000 lamb that right. Or they don't do serverless at all right, but some companies, like the one that I'm at right now, has over 100,000 lambdas right. So you don't do lambdas, you only do EC2s.
Speaker 1:So then I got to go piece together another solution to protect my lambdas. The organization wants to move into containers, so I have to find a solution that works with containers. Wants to move into containers, so I have to find a solution that works with containers. But Froudstrike that I have on-prem, also offers a container solution. May not be the best container solution. You know, like it's a mess, right, and so you know companies.
Speaker 1:I haven't been, I haven't been at a company that's a hybrid environment that doesn't have at least two separate teams, one that deals with on-prem and one that deals with the cloud and you know that doesn't have two tech stacks, right, like, is that something that you're also seeing in the industry and where you know potentially there's a gap, right? Because I mean, man, I would love, I would love one solution to just see, see, to just see everything in terms of my current role, right, I'm, I'm the cloud security engineer and I only care about the cloud, right, if there's. I'm sometimes I'm in these calls and they're bringing up like on-prem, you know, colo, data center names and stuff like that, and I mean I just tell them I have no clue of what you're talking about. I literally couldn't tell you what brand switches we have. I don't care. So is that something that you're also seeing?
Speaker 2:Yeah, so I think there's a short term and a long term here and in a way, joe, you've actually hit the nail on the head on what we are trying to solve. The Nutanix Cloud Platform allows you to take your on-prem application, on-prem virtualized application and workload and move it, as is, into the public cloud. And if that sounds a little bit like magic, it actually is, and we do that today for AWS and Azure. Now, after you move to the public cloud, obviously everything that you're doing long-term in terms of the security add-ons will continue to work. But if you start consuming new public cloud services, then you have to think about how do you secure those services? Right, what is happening?
Speaker 2:And going back to what I just said, right, there is incredibly little upside to taking your traditional on-prem work cloud and then refactoring that for public cloud usage. You could do it. You might get some benefit. You're absolutely right that it might not be fully efficient, but it turns out it's still a worthwhile thing doing, because the moment you start refactoring, it's a little bit like remodeling your house um, you want to replace, like you know, a faucet in the sink and then you pull out the faucet and you find out you have lead pipes. And so you take the trace the lead pipes all the way to the basement, and then you find out that, oh my god, there's all the way to the basement. And then you find out that, oh my God, there's asbestos under the basement. And so now you took out the basement and before you know it, what was your $500 faucet replacement? Turns out to be a $50,000 house remodeling. So I kid you not.
Speaker 2:So before I came to Nutanix, I was at Intuit and we moved TurboTax onto AWS. And I tell you not, there was code in TurboTax. This won't surprise you. That was written in Pascal in the mid-1980s. So good luck trying to translate that into lambdas, right?
Speaker 2:And so I think there are certain workloads. And so I think there are certain workloads, most of them traditional, virtualized or sort of native server workloads, bare metal workloads. But it doesn't actually make a whole lot of sense from a developer, productivity or human capital perspective to refactor them. But then the innovation you're absolutely right needs to happen in the public cloud. And so part of the security arrangement and the security operations there is leverage, whatever you have, and then make sure that everything new that you're doing in the public cloud you actually find a way to secure them effectively.
Speaker 2:The public cloud actually offers a whole bunch of benefits from a security perspective.
Speaker 2:There are challenges as well, but one of the benefits is that the approaches that you can use in the public cloud actually can lead to better security overall.
Speaker 2:So if you move away from a traditional, you know crunchy sort of exterior free lateral movement inside the firewall to a model where you don't really trust anything, then you have to end up hardening the hosts. You have to make sure that your ability to detect something is really fast. In the on-prem, you know I'm sure you've seen stats like it dates more than 90 days for most organizations to detect whether there's been intrusion In the public cloud. 15 minutes is a lifetime, and so not only do you have great tools in the public cloud, it's almost necessary in the public cloud to have an active and response system, and so that forces you to react and respond to a lot more security incidents which you may not even have been aware of in the private, in the on-prem world, in the first place. So you're right, I mean it isn't easy, but if you do this right and if you leverage the right underlying technology, you can actually harden your overall environment and make them that much easier to secure from a security perspective.
Speaker 1:And that kind of circles. Back to what you were saying before. You know security professionals really understand the security side of systems and how to make them better, how to make them more secure. And the system engineers, they understand their systems. You know, inside and out Same thing with the network guys and everyone else right, and it's the combination that makes it better. And I feel like there should be more collaboration when companies are moving to the cloud and migrating more things to the cloud. You know it always kind of leans on one team to kind of do it all and security is typically catching up right after the fact. But it's really important, you know, to have those experts in the room working on this thing together and especially having the trained cloud security people in the room saying, hey, this is how this service works, this is how they expect you to write your application because of these efficiencies that are built in so for us to utilize it properly. You know we want to make sure it has facts 100%.
Speaker 2:In fact, I think there's a great analogy between security and quality.
Speaker 2:It's not just the security team's job to make everything secure right it goes. They may be the tip of the spear, they may be the front end of this whole security apparatus, but the people who build the software, the people who deploy the hardware, all the way down to the receptionist in the front lobby to prevent, you know, social engineering that acts right, they all need to contribute to the overall security posture of the organization. You know it's not just the person who finds the bug in quality engineering. It's not just their job. To ensure quality, the developer needs to write high-quality code, and security is similar. You really need to have an awareness of how your systems can be taken advantage of. Your systems can be taken advantage of and while operations or functions like security operations are best done by dealing with a specialized team, what it takes to build secure systems in the first place is very much a responsibility of the developers, the engineering teams, the product managers. They all have to care about this to make sure that you know you end up with something that's ultimately useful.
Speaker 1:Yeah, it's a really good point, you know, and unfortunately I wish we had more time, but you know I try to. You know, stay within the time frame that we discussed previously, within, say, within the timeframe that we discussed previously. You know, it's been a fantastic conversation. I really enjoyed, you know, having you on. I definitely want to have you back on if you're interested. You know, before I let you go, how about you tell my audience, you know, where they can find you if they wanted to reach out, and you know, I'm sure everyone knows how to find Nutanix, but in case they don't, maybe shout out Nutanix as well and tell them where to find it or where to find the product you were referring to.
Speaker 2:Our website is the best way to find out more information about us wwwnutanixcom. That's N-U-T-A-N-I-X. If you've ever read Asterix and Obelisk's tonics, we started the name of our company. We have sort of new tonics. That was sort of what we were meant to be a new kind of infrastructure, a new kind of tonic. If you will, you can find me on LinkedIn. Yeah, I think I have a profile there and that's probably the best way to reach out to me. Awesome, Thank you so much. I really enjoyed the conversation and I would love to be back, if you'll have me.
Speaker 1:Yeah, absolutely, we'll definitely have to figure that out. All right, well, thanks everyone. I hope you enjoyed this episode.
