Turning Hurdles into Success: Ganesh's Tale of Persistence and Innovation

Speaker 1: 0:00

I was going. Ganesh, it's really good to finally have you on the podcast. I feel like we've been trying to get this thing going for quite a while now and I'm just really excited to finally have you on.

Speaker 2: 0:13

I appreciate the opportunity to be here. Better late than never, so glad to get started.

Speaker 1: 0:20

Yeah, I guess that's one way of looking at it. You know it's. It's just, it's interesting how your schedule can can play out, you know, when it's a. It's been a crazy year for me, that's for sure.

Speaker 2: 0:34

I can only imagine. Probably with the schedules that you run, it's probably powerful the course, but yes, when it comes to reality it's a different thing.

Speaker 1: 0:41

Yeah, right. So so, ganesh, you know I started everyone off was kind of telling their background, right, talking about how they got an IT. What was it about IT that really piqued their interest, that wanted them, that made them want to, you know, get into this field, right, because this field isn't really for everyone. But you know, I've done over 150 of these episodes and I haven't heard the same background twice, right, like I've talked to former opera singers, I've talked to, you know, former physicists and somehow these people always find their way into IT. So what's your story?

Speaker 2: 1:21

Yeah, I don't know whether I'm going to be as exciting as others, but let me do my best. So I started with a couple of different things, but one way to give you a little bit of my background, if I were to summarize it in the shortest possible way, I'm an engineer by training, as in. That's what I went to school for. A technologist by vocation that's what I did for the first majority of my career and arguably an entrepreneur by choice. What that really means is when I come to an edge, I jump first and pray real hard that I can find sure, but I've been incredibly fortunate to be in the company of the right people at the right time, right. So that's what has sort of led to the success in terms of venturing and being an entrepreneur. I'm happy to give you more background on what's been built up to where upticks is today, but on myself, that's how I characterize yes.

Speaker 1: 2:23

Yeah, it's a really interesting. I feel like it's an interesting question to start off with to kind of get the feel for how the guests got started and whatnot.

Speaker 2: 2:41

I can give you a lot more color on that, just to elaborate. So, in terms of interest in IT, of course it is due to the training as an engineer and the curiosity then took me to be a software engineer and technologist through majority of my career. But in terms of the venture itself has applied to core cybersecurity. Me and the core funding team here at upticks we come from a background of having scale, and by scale I mean enterprise scale, as in building things for large operators like AT&T and Comcasts of the world. We built primarily technologies which enabled these large operators to make revenue through the tooling that we provided as entrepreneurs from the past. However, the revelation, at least, which piqued the interest to get into cybersecurity at large, was a peripheral understanding that with the knowledge that we possess, which we were using only for constructive purposes, if someone had a different, maybe malicious or a different intent, but with the same knowledge that we did, they could definitely cause a lot of harm and as you see what's happening around us. So that's what prompted us to start thinking can we make a difference, to be on the defenders with the knowledge that we possess, having a good understanding that those who have a similar skill, but with the offensive mindset or the malicious mindset, could do other things, and this happened when we were at the prior venture that we did and we were acquired by Akamai, and some of what we saw in terms of debug and diagnostics then led us to the belief that maybe the visibility that we encountered in the past, maybe that can be made available for cyber, and that's how the venture was formally conceived around eight years ago. We took money and operationalized the venture by capitalizing it in the summer of 2016 and seven years on, here we are.

Speaker 1: 4:58

So that's really interesting. You always hear about these big tech companies and the scale that they're operating on, and I read an article maybe it wasn't an article, it was just a random post that talked about how Google can't really purchase products to manage their environment. But I have to actually create it, because the scale is so significant that very, very few other products on the market would even come close to being able to manage the scale. And then, when you factor in the features and functionality that they may want, they don't want to rely on a third party vendor for that. Can we talk a little bit about what it's like to design for that scale? Because there's not that many people in big tech, right, there's several thousand engineers and whatnot, right, but not everyone comes from that background. And so, for even someone like myself, the largest company that I've worked for is about 650,000 employees. It's a global company, and even when we start talking about Amazon scale, I can't even fathom it. I can't even picture it, right. So what is that like? Trying to solve that problem?

Speaker 2: 6:29

Yeah, that is a great question and where, if I were to share my own experience, to tie it back anecdotally, what I can reflect upon is the fact that scale produces a different kind of challenge than what you might encounter otherwise, and, in the context of what the learnings were, they were not necessarily tied to cybersecurity, but they were tied to visibility and observability. For a different reason it was predominantly for debug and diagnostics. When you're operating a very large distributed systems, no matter what the application is, you need to have intense amount of visibility such that you can quickly diagnose in case things are trending in the long direction. And all of that is tied these days into site reliability and other engineering. But the premise of why you might deduce that something is not working is based on what's otherwise called as a paradigm of observability. So what scale teaches you is that you can't do things in a onesie-toesie way, but you need to look at a distributed system as a corpus of large system which is constantly streaming some sort of a telemetry to you, and you need the ability to apply analytics based on that streaming data and quickly figure out where exactly are the signals which are noteworthy, because clearly you can't pay attention to everything. That means you need means to extract what's worth paying attention to. So these were some of the deep learnings which heavily influenced us to say, can this paradigm be applied in the realm of cybersecurity? Because, due to the proliferation of cloud at large scale, can you start deducing what's wrong in the systems by observing their behavior, by doing so from outside in, by collecting telemetry from them and applying streaming techniques. So that was in some ways a lesson that we had the good fortune of learning in a different edges and domain, but the luxury of applying it to cybersecurity in this current venture. Hope that made sense. I'll pause here, happy to zoom in and double click, but hope I've shared an anecdote which is relevant to what you were asking for.

Speaker 1: 8:56

Yeah, I think that makes sense. I wonder. So I think that this poses a unique challenge. So when you're starting a company, when you're creating a product, you want to it's human nature, you want to take in every single customer that you possibly can to get them your product to not only benefits them, it benefits you. When you're when we're talking about creating a product that has to scale like that and you're early on, you know, in your development process and the lifetime of that company, do you think that it is also important for you to choose the right customers as like, as a side note from the customer choosing you? The reason why I asked that is because I actually used to work for a company. It was very small, you know, they had been around for I don't know, maybe 15 years, something like that, but they were still. I mean, it felt like it was a start-up and we had certain customers that had been around for forever that were just so resilient to any issue our product would encounter right in their environment, no matter how sensitive their environment was or whatnot. It was like they were used to it. They knew that we would get it resolved and they knew that they had a reporter in a certain way and like they just understood, right, like this is a part of the game. And then we had other customers that were extraordinarily difficult to deal with if they encountered a brand new you know bug or an issue with a brand new version. And so I can only imagine, right, because there's only so much that you can design for without without having a problem in front of you, right? So I think it poses a unique situation where you have to have a customer that's understanding like hey, you know, we're starting out, we think we're doing something special here. If you can hang in there through a couple iterations of these bugs and whatnot, like we'll get there. Is that something that you've experienced? Is that something that you learned? Or am I completely out there and off base?

Speaker 2: 11:14

Now, I think that's the I don't want to say. In some ways it's the very nature of progressing through the journey of a startup, because when you start off you can do two things you can figure out if there is a little wedge or tooling, go really deep, or you can arguably take the approach that we did we built a general purpose platform but in both cases, in the initial phases of the venture, where you're iterating for that initial product market fit, you clearly go through the phase where there's a combination of ideation that you bring to the table which gets a customer excited, so much so that they are willing to partner with you and arguably go through that phase of trial by fire in production, because they see in you the promise, that a pain that they felt they've not been sufficiently able to solve it any other way, which is why they are willing to invest in you and your venture and arguably go through that process. And I'd say that we were fortunate that while we had our own here of challenges, our customers saw sufficient value to persist with us. And of course, it took a few years to get them to like really large and I'm talking about 150,000 plus server environments where we've been fortunate to get operationalized, but it didn't happen overnight. We had to prove and we had to persist and we had to do everything that you just outlined, because, at the end of the day, it's not that, while we had a vision and the product work for most part, making sure that it fits in an enterprise environment where there's a lot of diversity and that diversity introduces pain and challenges is what one had to encounter and overcome, and we were fortunate to do so.

Speaker 1: 13:12

Yeah, it's a. You know it's an interesting way to live a life. Right is running a startup and all the different stresses that come with that. You know it's an interesting way even to start your career. You know, like for me, right, I started out as a startup and being able to, or having to, wear several different hats, you know, all on the same phone call, right and taking a problem and owning it all the way from start to finish, not being able to escalate it. It's like, you know, no, I am the escalation point, like they call the right number, unfortunately, and I'm the person that has to take this thing from. You know, 8am until 4pm. You know it's always interesting to hear about everyone's journey in the startup phase because it's different but similar in a lot of interesting ways.

Speaker 2: 14:14

Yes, you know, I have a very simple philosophy around this, and others might disagree. The bottom line, I think, is there is no shortcuts when you jump on your journey to get to a successful point. And if you were to imagine X and Y axis and Y is like you know how much time it takes to be successful on the other axis, then you realize that there are no shortcuts. It's guaranteed to take time to be successful, at least statistically. I think that's accurate. The only other thing which is really important is that the journey to go to the top is going to be jagged. It's never a smooth line, right, and that's your point. It always takes time and it's always bumpy, but if you're able to endure the ride in the company of the right team, I think it makes the biggest difference.

Speaker 1: 15:08

Yeah, you bring up a really good point. You know that there are no overnight successes in this world, that's for sure. And I think that that kind of that hit me when I watched this interview from Kevin Hart I think Oprah might have been interviewing him or something and they said oh, you know, you're an overnight success. Like how does it feel? And he goes overnight. That was 12 years of hard work, of people booing me off the stage, of people, you know, not knowing my name, me not being able to, like, feed myself for several days, Like that. That was a long time. That was 12 years of being not giving up and that really resonates with me, right, because in the current society and how everything is, you see, it's like you see it all right in front of you immediately, right? So now you, you're matching up your life with this other person's life and they were probably in it for 10, 12, 15 years, right, and you're saying, well, I'll never get there. That's not for me. But in all actuality, is that person that spent the 15 years doing that to master it. They just didn't give up. You know that that's the only thing. Like, they had their disappointments, they had their failures. They just didn't give up. They kept going, and I think that that is that's a key skill in life overall, right, but it's a key skill that you must have to really be successful in anything that you choose to. Would you agree with that?

Speaker 2: 16:46

Yes, absolutely, and I can give you some anecdotes based on my own experience, because, in our seven years of existence, to build the first core part and do the validation, it was roughly an overnight success of five and a half years in the making. Because in the business of cybersecurity, we are today a provider of two things. If you have your technology, from the laptop to the cloud, if the cliché is software is eating the world, the question is where is it produced, how is it operationalized and why does it end up being a crown jewel of an organization? At the venture that we are, we specialized in securing that arc of productivity. We arguably made a case five years ago to come up with this approach of using a paradigm of observability which probably was not well understood or well received. Of course, we had to build the platform at scale to validate that. Now, of course, we have a really nice word which our marketing team has put together, which is called a shifting up. But what really entailed was looking at all these things which are a part of going through that cycle of building your crown jewels. How do you observe the laptop, the SaaS services, the cloud infrastructure and then draw conclusion is something going wrong. How can we use the same data to establish trust and all of that. And that took us time and, with one specific asset, to secure and build it. It took that overnight success and it took that long and now we are in a position to reap the benefits of this shift up approach, and we see a lot of parallels. Of course, when we were doing it, we were thinking who else might have done something like this, and we saw the likes of SAP and the likes of Salesforce and others do it, and we were able to connect the dots that it took them a fair bit of time to get to where they are, because this observability approach, built on a platform, is not something which happens overnight. But, to your point, you have to be persistent and it takes that much time to be successful.

Speaker 1: 19:12

Yeah, it's an interesting journey. So we talked about designing a product for scalability for extremely large environments. I would assume that that really significantly impacted how you designed upticks, the upticks platform. Right, because it's a cloud first solution to provide visibility into the you know, your multi-cloud, your single cloud environment. What's the difference, in your mind at least? What's the difference between a cloud first product and a product that you know legacy on-prem, that was rehashed into a cloud solution? Me, from the engineer perspective, there's a gigantic difference, right? Those other legacy solutions. They typically can't scale very well. They're typically very configuration heavy. You could spend months configuring those tools to do very simple operations across all three of the clouds. In that valuable time that you would have had, you would have had a cloud first product that would step in and would have done it in 30 minutes and you'd be up and running, right, yeah, so from an engineering perspective, there's a huge difference. But from your perspective, from where you're sitting, right, what's the difference that separates the two kind of rules of thought?

Speaker 2: 20:49

Yeah, so the there are two dimensions. One, scale, of course, is the easy word to use, but the real question is in the modern environment, why does scale matter? Scale, of course, is the part in terms of your ability to cover a wide spectrum and go for large environments, but in addition to scale, there is a big part is the diversity of the environment and the rate of change in the environment too. If I were to characterize the problem statement to then highlight the reasons for why a cloud native approach makes a difference, if you're to look at what a prototypical user who might want to work with optics and what challenges they might face, their work might look like something along these lines right In the organization, their users might either be interacting with SaaS services because they work off a laptop, they have a Wi-Fi and they connect to Google, or they connect to like GitHub or do something. But the engineers they assert their identity with the identity provider, like OCTA, they connect to something like GitHub to like, do the source code, check in checkouts, they develop the crown jewels, then they push it into some kind of build pipeline and then they operationalize their tech by storing the artifacts, the builds that they've generated and pushing it into one of the clouds, and they might use modern environment like Kubernetes to containerize and package. Now, of course, there is the scale part of all these, each one being at large scale if you're a large organization, but there is the diversity of various things that you need to account for. Then the other part to account for is the rate of change. With the way the modern world is, to make sure that you are able to instantly adapt and provide new features. There is constant software which is being built and it's being operationalized such that changes happen within a few days in some cases or, worst case, weeks, as opposed to like months of release cycle in the past, which is historical data center centric, on-prem approaches, because it is a lot harder to like, operationalize tech and a lot harder to debug and if they were mistake, you can't really push things out. Now the scale, the diversity, the rate of change introduces various different problems when it comes to both security and understanding. If things go wrong and the way you have to tackle this becomes a different problem statement, especially in the context of cloud native applications and how you secure them. And to secure that then you have to be as purpose built as the applications itself, because it needs a new paradigm and that's where we've been fortunate to build a platform to make a difference. I'll pause here I can dig in further on this because this is a topic that I'm extremely passionate about but hopefully that gives you some color and perspective on the problem statement itself. Thank you.

Speaker 1: 23:57

Yeah, absolutely. I feel like you know, I have seen it where in a few cases, you even have to explain almost like what the cloud is to some people, of how, you know, updates can happen daily, right, and not impact you at all, and you not even notice that there's an update. It's like, well, do you use Gmail? You know, and if you use Gmail, that thing is updated probably every week and you've never noticed as a single update. I have you, you know, I was working at a place and I was trying to get rid of the legacy ping identity solution because it was on-prem, it just wasn't going to work for us in the cloud, wanted to move to another SSO solution that was cloud based, you know, and the principal engineer that was going to, you know, own the technology was very confused as to how they could update their product so often. And I'm sitting here like how does this guy of all people, how does he not understand how this works? You know, and it's interesting that in 2023, we still have to, you know, kind of describe that and go into that a bit. Is that something that you have also seen or have? You know? 99.9% of customers, you know, moved on and they're not dealing with that legacy thought pattern anymore.

Speaker 2: 25:26

I think they have moved on. They're not dealing with the legacy thought pattern, but they do have a lot of residual legacy in large environment because their digital transformation journey is not complete. Well, I think people certainly have an appreciation, the reality which sometimes grounds them as the diversity of their resources. You know as easy as it is to think that you might have the latest version of Red Hat or the bounty in the cloud that you can take advantage of, what they're left with is you know, 12 or 13 years ago there was Red Hat 5. It was running on a dual core machine with 8 gig RAM. It's running something which is machine critical, engine rating, a lot of money, and they're aware that it needs to be moved. But you know, business reasons prevent them from moving it right. So that one consideration. I also want to make an observation, if I may, based on your first comment about availability of Gmail and other applications. Most people probably take it for granted because the rate at which, or the frequency with which, they access their Facebook and Google these things probably are far more reliable than the banks that they dealt with from a digital perspective. Right, because it's downtime implications to these providers are far more bigger than if a bank is down. You might go to another ATM or you might wait, but if you're not getting your email or your messages, you're not able to see your Instagram or whatever else. I think that there's going to be a bigger outage, right? So outrage, rather so. I feel that you know the reasons why are different, but the reliability of these applications, thanks to cloud and SaaS, is just incredible.

Speaker 1: 27:10

Hmm, yeah, you put it a really, a really good way. So, you know, can we talk a bit about upticks and how the platform takes in the different signals from the cloud and then provides intelligence around it. What's the basis that it provides this intelligence? And before you dive into this right, Because this could go on forever I just wanted to mention I saw the product for the very first time at RSA it might have been 2021 or 2022. And it was a rough product, you know. I'll be honest, it was rough. You could see that it had, you know, good bones, good infrastructure there, that something special was actually coming. And then this past year, when I went to Blackhead and Defcon, you know, I got to see the product again. It looked like a totally different product, right, it looked amazing. To be completely honest with you, it looked really great Very intuitive product, great UI. I understood what was going on, you know, right from the start. I didn't need anyone to explain it to me, even though your team did a fantastic job of walking me through it, and so you know, I just wanted to point that out of how, just in, you know, a year, 18 months, right, like your product, made a significant leap in usability and, you know, in the value that it actually provides to an environment. And again, this episode isn't even sponsored by you guys. I just enjoy the product.

Speaker 2: 28:45

Thank you, and that's much appreciated. And I'll tie it back to what I said earlier. You caught us probably in the four years of the five and a half years it took to actually get to where we want to be at scale. It's a great observation and a very candid one, which I sincerely appreciate, because I think it's factually accurate To dig in a little bit deeper to understand why that's the case. We arguably chose a completely different approach to building a product and what problem we want to solve, for Our thought process was to provide security using the observability paradigm. Now, what that meant was you know, you know. We of course, have a really nice way to outline it, we call it as shift up security, but the basic tenets and principles were that if there are a set of attack surfaces for which you want to provide security coverage, at the end of the day you provide security coverage to reduce risk for any organization, and risk stems from either vulnerabilities and misconfigurations or genuinely threats which are behavioral in nature, because the misconfigurations or vulnerabilities that you have have been exploited by someone and they are posing a threat to the organization. And to understand what this risk reduction means across a set of asset categories, we chose arguably harder route to market then, which is to say that we will build an abstraction using a series of sensors and connectors which will provide us with in-depth telemetry, and we will apply analytics on that telemetry while it is in flight as well as on a historical basis, so that we can build the necessary security controls towards reducing the risk. Now, to realize that vision, of course, we had to build these sensors and connectors using a structured manner which transmitted the telemetry, for example, for XDR and endpoint. We do so from runtime environments, from the cloud. We do both agent and agentless, but we connect to it such that it sends the data to us. So the question is how do we scale, ingest the data, apply analytics to extract signals so that those signals then, in turn, can be used both for establishing trust, as in compliance, and auditing, and all that as well as doing threat detection. And you probably caught us at a point where the infrastructure was built to ingest the data in a scalable manner, but we perhaps were lacking the ease and the simplicity that's required by most organizations, who are bootstrapped in terms of their time to draw conclusions and with the ability to build that platform in a scalable manner. What's been happening in the last couple years is our ability to extract insights on top of the platform, and those insights are the ones which translate directly into the CNAP, cwpp all the analysts have really nice acronym soup for that and we provide coverage because that translates into security controls, and thank you for sharing this. Where you probably next encountered us is that we then were able to actually show the promise of that telemetry by generating actionable insights, and I appreciate you sharing that. It was self evident for you when you saw it yourself right. So that's a tribute to our product team and our marketing team that they're in a position to make that happen. But hopefully that gives you an anecdotal journey tying back to your two points of observation and where we were along in our journey. I'll pause you for a second, if I can zoom in on anything else. Yeah, absolutely.

Speaker 1: 32:47

You bring up a really good point right is presenting actionable information and actionable intelligence to the engineer, to the end user, to actually resolve issues within the environment, and that's actually a huge area of the cloud and cloud security solutions that matters a lot more, I would say, regardless of the environment size. About a year, year and a half ago, I was POC'ing a CSPM solution and the deciding factor for me was ease of use, right? How quickly can I get this thing stood up? How quickly is it going to give me information that I can actually act on? And how can I take that information and take that information and take that information and actually act on? And how can I take that information and maybe even resolve it straight from this console, right? Rather than going into AWS or Azure and then GCP to resolve these three critical items, can I do it all straight from this platform or whatnot? Right? And that was absolutely a criteria that I had to keep in mind, because our team at that time was a team of two, including myself. We didn't have the time to really sift through 1,500 alerts a day and choose the five that were the ones that I needed to pay attention to and design a plan around how to resolve them. It's like, no, I kind of need this solution to do 99% of that, and then I do the 1% and verify that that's what I actually want to do in the environment. I point that out because it's like that shift in mentality almost, and even at a larger organization that I'm at right now, that still matters a significant amount because I'm doing other things. I have 30 other things going on that I can't spend my entire day in this one console. I have an hour, two hours maybe, to get this information, make adjustments in the environment, vocalize it out, make changes in the processes and then move on. It's just a fast pace evolving area, I feel. Is that what you've noticed as well?

Speaker 2: 35:08

Yes, very much so, To your point about CSPM and its implications and threat detection on the other side. Virtually in all cases and this, of course, took us time, because when you do a platform-centric approach, it takes time to build everything, but in both scenarios you want to quickly surface something which is insightful, and perhaps this is what you're alluding to Context is the king, because if there is something noteworthy which is to be investigated, the context reduces the necessary time and it reduces dwell time and it makes a big difference because then you know that there is something noteworthy that you're going to act upon, based on the efficacy and the quality of the context which is provided to you. Our observation has been along those lines in terms of which has been the lead up to our product improvements, whether it is for CSPM and the context around agent less, where you can provide a lot of visibility, which is static in nature, to the agent-based approach, where you can actually do behavioral detection. How do you provide that in a rich way, not just your own way, but you align it with something like MITRE, which allows an organization who's read something and they have some approach to understand. This is how threat actors might behave and when you use that paradigm to lay things out, it's a lot more easier for us to digest. Yes, a long-winded way of telling you that I'm 100% aligned with what you said, irrespective of the size of the team, as to how quickly one has to surface the context and provide ease of use.

Speaker 1: 36:50

Yes, it's really valuable when you present the information in a way that relates to a framework or a standard, like MITRE that you mentioned, because sometimes with these changes that you need to make within the environment, you need the proof, you need the actual evidence saying, hey, this is the actual control that we are failing. This is why this is how we resolve it From the engineering perspective. It makes me look really great, at least to my management team, when I can go to another, let's say, infrastructure guy or a network guy or a developer and say, hey, this is exactly what we need to do, why we need to do it and everything like that. Historically, that would take a couple of days to put that information together because I have to pull all this information from so many different resources and check it and triple check it. But you know, if you have a solution that's doing that for you and you can just take it and literally send it off to someone, that saves me a whole lot of headache. And I always appreciate it when products you know take in to account the end user and what that end user has to go through on a day to day basis, and you know it's like, how do, I make their day easier. You know, that's always, at least from my perspective that's always appreciated, it's always noticed and it provides a lot more value than you know any other solutions out there, in my opinion.

Speaker 2: 38:23

Now you bring up a great point. I mean, if I were to just give three simple examples to your observation, what we've seen where we've had great resonances one, you know, simply in the context of the visualization of the CSPM and all that if there's ever a conversation between the security team and the development team, you can use something like a security graph or attack path to have a conversation. Look, this is what a visual thing about where the misconfigurations which could lead to a whole exist, and it's an easy conversation between the security operations and the developers of the DevOps team so that they can fix it. Second, if you are any good site organization, you're in the context of a compliance and audit, the auditory activities simply to establish value to the auditor, to say, okay, here's the audit tail which tells you that this control is not there. And now it's there. And all of that data makes a big difference. And third, of course, is genuinely on the cyber side. Now, whether it's detection and response or post factor or speculative hunt, if you have the depth of telemetry and the data, not only can you surface a few things which are aligned, but that's the part where, if things are trending in the wrong direction because, god forbid, something has really gone wrong in your organization. At least you can dwell, reduce the dwell time by knowing and scoping what was the lead up. And where we've been fortunate is that the intersection of these three use cases for a bunch of different asset categories, which, of course, gartner likes to characterize as XDR and CNAP. These are words, but both in terms of workloads and endpoints, we've been able to make a big difference. It certainly took time, but we are at that point where these three examples to just to back up what you said we've been very fortunate to really easily address where the ease of use to make this happen.

Speaker 1: 40:23

With it being a cloud solution and natively, I guess. The cloud providers are very fast moving and they're always revolutionizing and adding new services and just everything you can imagine they're adding behind the scenes. How does the company in your position stay up to speed with all the different changes that are coming? I think last year AWS added something like 27 new services. I couldn't believe it because I feel like maybe I'm legacy cloud where I'm still stuck within Kubernetes and EC2 and S3 buckets. How does someone in your position say okay, we're going to consume these new services, we're going to figure out the security posture items around them and then we'll be able to provide insights? It sounds like that's a whole other company to be quite honest. It's not just a team, that's a company.

Speaker 2: 41:27

That's a great question, by the way. Here is where investment upfront, when it comes to prudent architectural and technology choices even if that meant that we had to do extra development to accommodate this has made a difference for us. To put that into perspective, here is how we see these things at a fundamental level. If you take an operating system, whether it is Linux, windows or Mac, you can characterize it in three dimensions. One is to say what is the configuration of this machine telling you? Because that tells you about the inventory compliance things which are very prescriptive in nature. Second, every operating system has a conduit to tap into the behavioral changes the system is going through, as by a proxy of system calls. By observing that you can draw conclusion what is the impact of the behavioral changes after you know what the inventory is? The third part is every operating system today tells you about the ins and outs and flows. If you say things can be broken into these three dimensions of configuration, behavioral change, detection through your audit trail and all of that, and Cisco activity trail and the flow law and in and out cloud is exactly like that in some sense. It does not matter whether it is the AWS, gcp or Azure, they all have configuration information, they all have audit trail and they all have flow logs. Even if you take it to the next level of a SaaS service like GitHub or Octa, their behavior is similar and to your point. If they start adding more SaaS services as a part of the cloud offering, that's just more of something which is in a similar paradigm which can be broken down into the new service coming in. Does it have its configured state where I can tell you what its security posture looks like? Does it have a behavioral trail where I can tell you those changes? Are they going to result in something wrong? In and out the flow logs related to that? Does it tell you where things are being accessed which are inadvertently and whether there is some kind of outlier activity? The abstraction that we've built around these three and a very structured approach using ETL-free pipelines took us a bit of a time to build this IP, as what has been the fundamental difference in our ability to absorb the rate of change of Cloud Service providers providing new things. Clearly it took us a time, but we feel very well equipped to handle that. I know it was a bit long-winded but I'm happy to delve in further, but you touched upon something which is key to our IP and where we've been able to really take advantage of some of the design choices that we made as an engineering organization.

Speaker 1: 44:23

Yeah, absolutely, ganesh. I feel like we almost need another episode together to dive into this more. But before I let you go, I want to get this one last question in when do you see the upticks platform going in the next few years? As we're thinking of the Cloud and how the Cloud is expanding and growing, revolutionizing how everyone does IT, where do you see upticks going along with the Cloud providers as well?

Speaker 2: 44:58

Great question For us it's to really secure that arc of productivity. But, as you can imagine, security practitioners secure things because they follow either transformation or IT and engineering choices made, which is to say that a CTO makes a choice of how to operationalize something in the Cloud. A CIO might make a choice of something in the Cloud or services which people pick. So where we are heading is as the result of this ongoing digital transformation and more. If the endpoint is a means to access a service, whether it is for creativity and production of software, or it is because from the endpoint people access SaaS services, much like how if they build something and pushing something to the Cloud. So that trifecta or quad-fecta I call it, of endpoint, cloud and containers to second as a part of the thing, and SaaS services is what we plan to secure the infrastructure that we've built. Along the lines of what I said, the ability to ingest configuration change, trail activity from these services and the flow logs is going to board really well for us. That we feel is in line with the transformation which is happening. Our goal is to observe and secure this pipeline from the laptop to the Cloud and the services which people interact with from their laptops.

Speaker 1: 46:30

Yeah, it's a really interesting place. Me personally, I'm really excited to see how your solution and other solutions like yours will be growing and changing. From the podcasting perspective, I get to see it from almost like an outsider's point of view, while still having that inside knowledge, almost, so it's a fascinating area that's just always growing. So, ganesh, right before I let you go, can you let my audience know where they could find you if they wanted to reach out to you, where they could find upticks, if they wanted to learn more about the platform, about your solution?

Speaker 2: 47:13

Yes, thank you for this opportunity. So, to your listeners, we are on the worldwide web as everyone else's. Uptickscom is where you'll be able to find a lot of information about us. Feel free to reach out to us on Twitter. Our handle is at Upticks, same as the case on LinkedIn If you search, you'll be able to find us, but we have a tremendous resource library on our website, which is, I don't want to say, independent of what we do, but it's a very rich learning thing and hopefully, while you're there, you might be interested in what we have to offer as a product company too, which is to secure things from the laptop to the cloud, and we call it as a unified XDR and CNAP platform. Our approach is what we characterize as shifting up. I'll pause here, and I appreciate the opportunity for me to outline this. Thank you, joe.

Speaker 1: 48:08

Yeah, absolutely, and I really appreciate you coming on and I hope everyone listening enjoyed this episode.

Speaker 2: 48:16

Thank you for the opportunity. I really enjoyed the conversation.