Techzine Talks on Tour

How does a white hat hacker become a cloud security leader?

Coen or Sander Season 1 Episode 11

This week's episode of Techzine Talks on Tour is a rather special one, even if we do say so ourselves. At the RSA Conference in San Francisco, Sander Almekinders from Techzine sat down with Anand Prakash from SentinelOne. They chatted about how he, a white hat hacker, built one of the most advanced cloud security platforms in the industry. Well worth a listen, so go ahead and click on the play button below.

In their discussion, Anand and Sander touch on a variety of different topics. Of course there's the story about how Anand became an ethical hacker. This story itself is a reminder that grasping the opportunities when they arrive is more important than trying to plan your whole life beforehand.

Being an ethical hacker gave Anand a distinct advantage when he starting thinking about setting up his own company. It all starts with the attacking mindset that a hacker has. That mindset became visible in what PingSafe, the company he founded and headed, offered. SentinelOne saw potential in PingSafe's offerings and decided to snap up the company. PingSafe's product has now become Singularity Cloud Native Security.

Tune in now to hear all about how a guy from India went from exposing flaws in Facebook to developing a cutting edge Attack Engine to secure cloud environments. You won't regret spending thirty minutes on it.

Speaker 1:

Hi and welcome to a new episode of TechScene Talks on Tour. I'm Sander, I'm at the RSA conference at the moment and I'm here with Anand Prakash. He is the co-founder and CEO, or was the CEO, of Pinksafe, which was acquired by SentinelOne in January. Welcome to the show, thank you. So we're going to talk about what you did in the past of being a white hat hacker and how that made you into a successful kind of CEO and also now part of Sentinel-1, and what it means for cloud security in general to take a little bit of a different approach to cloud security, right? So let's just start with the beginning. How did you get into the white hat kind of ethical hacking space?

Speaker 2:

Yeah, so like crazy, but this started in 2008. And I was like 17, 18 years old, saw someone posting about how to hack Orkut account and I was like I should also try doing it right. And it was a simple trick called phishing. I followed up 10 steps and sent the link to one of my friends and they entered their username and password so that so it was that easy to it was that easy, like basically a script kiddie trying to just follow some steps, Very less technical knowledge and I was able to do this.

Speaker 2:

But the main trigger point, that's what got me interested into the field of security. Then I did my bachelor's in computer science in India and in 2013, in my third year, I saw a tweet from a security researcher and he posted that he got like 500 bucks for reporting a bug in Facebook.

Speaker 2:

So you thought, oh, it's an easy way to make money, yeah easy way to make money and so I was like I should also try it. I had some loans to pay off and stuff, so I was like I should try it and I tried for like a couple of months, three, four months and then I ended up figuring out a buck in Facebook.

Speaker 1:

Do you think it's as easy as it used to be now to do this, to start doing this? Because obviously we're now 17 years on since you started. The world has changed yes is it still that easy to start with uh with ethical hacking or with uh with white hat kind of yeah?

Speaker 2:

I think starting in ethical hacking is easy, but, uh, finding such kind of bugs is like really sophisticated. Now, like earlier, there the hackers they used to find a single bug, exploit the company, get the data out of the system. But now, like attackers, they change vulnerabilities, like they find a low severity bug, then another medium severity bug, then a high severity bug and maybe club all three of them to create a very high impact bug and that's how they hack. So over the period of time, the modus operandi, the way attackers used to attack, that has changed significantly and companies have also matured. Technology has also changed. So when I started it was like all PHP. I was a PHP developer.

Speaker 1:

But now you find, so it's also harder now to find these bugs and to find these things. So you found a bug in Facebook and thought, oh, that's interesting, even if you can hack a company like facebook or you can find a find a bug in there. Um so, and you did this as a sort of a hobby, or was it?

Speaker 2:

yeah, mostly like I started doing this for paying off loan because I had some loans to pay and um, uh, then it turned into into a and then, like one day, I was sitting and realized that, indirectly, I'm helping secure billions of user data which is out there. For example, some of my findings were like hacking into any Uber account in the world, compromising any Facebook account out there, tweeting from any Twitter account. So these are like very high impactful bugs. Imagine I'm able to see your location live, right. Where are you going? If I'm able to use your account, if I'm able to see your private messages right, then it creates a problem for billions of users which are using these applications. So I thought that this is impactful and I should continue doing this.

Speaker 1:

Yeah, because nowadays a lot of ethical hackers I speak, at least I talk to, they do that next to sort of a normal, regular job, right. So they have a job at the National Railway and they also do some ethical hacking and the employer knows about it and is fine with it. So it has a little bit of the. It has a little of a hobby vibe ethical hacking. Is that correct?

Speaker 2:

Yeah, that's correct. Yeah, that's correct. And sometimes it's like high paying job too. So that's another thing. So people prefer and also like it helps you to sharp your skills because you get to see many different types of applications rather than you see the same one while you are working at a single company. So it helps you keep up to date.

Speaker 1:

So that's the core, but there are very few full-time ethical hackers in the sense, because most of them have another job, I think.

Speaker 2:

Yeah, most of them, I know some of them who are like completely doing ethical hacking but mostly they have a job.

Speaker 1:

So what started the ping? Safe fire. So to speak.

Speaker 2:

Yeah. So this was in, I think, in 2019, 20, when I saw that most of these bigger companies where I was founding Bugs on they were using cloud and all these companies they were using like so-called compliance cloud security products, like mostly solving for PCI, dss, cis benchmark. They basically had a compliance dashboard and trying to figure out issues and the other thing was, apart from this, they had another dashboard where they would see thousands of issues. It was too much noisy and, on the other hand, I did not have any access to these companies while I was finding issues in their infra right and what I realized was that I was able to easily compromise them like super easy.

Speaker 2:

Yeah, one day I would find an aws access key of that company on a public repo. Another day it's more like I find another subdomain takeover on that company which I could use to deface the entire, deface the domain, right, yeah. And other zero days which were like we were actually able to exploit and, uh, of course, report ethically to the company. So, while doing this for over the period of two, three years, during that time, I was like no other tool, no other product is able to solve it. So I saw a clear gap where attackers or ethical hackers were finding different kinds of cloud security issues, but the current tools what I call traditional tools were surfacing different kinds of cloud security issues.

Speaker 1:

Okay, because we're talking about 10 years ago now, something like that, or 12 years ago, when was that.

Speaker 2:

No, this was in 2019. 2019. Yeah.

Speaker 1:

So that's even, and because there were a lot of cloud security kind of solutions out there already, but they did the wrong things.

Speaker 2:

Yeah.

Speaker 1:

From your perspective? Yes. So what did they focus on then, instead of they focused mostly on compliance. Oh yeah, Compliance and surfacing vulnerabilities, which are not really exploitable.

Speaker 2:

So, I and my co-founder and my team, we thought that we should build out something which finds real exploitable issues in your cloud environment. Like these are the 10 issues which can get you hacked exploitable issues in your cloud environment.

Speaker 1:

Like. These are the 10 issues which can get you hacked. So you took a white hat hacker approach ethical hacking approach to cloud security. Yeah, was there really no other company that did that in 2019?

Speaker 2:

No, no, as of today also, you won't find any. It's quite weird, right? Yeah, it's weird, it's weird.

Speaker 1:

Why is that, do you think? Do you have an explanation for that?

Speaker 2:

So maybe, like maybe CISOs were at that point in time, were only focusing on compliance issues, and maybe cloud was new.

Speaker 1:

Probably also the easiest way to make money.

Speaker 2:

The easiest way to yeah, maybe, yeah.

Speaker 1:

I think so. I mean those are not your words, but those are my words, and I think also for CISOs it's the easiest way to keep their jobs, because that's what they, I mean. They need to be compliant with all this stuff, Otherwise they will not be, they won't be able to keep their job.

Speaker 2:

And sometimes it's true, also right. You have to be compliant if you are a bigger company. Sure, sure yeah.

Speaker 1:

But ideally you're compliant and go beyond that as well, right and be even more secure.

Speaker 2:

And the other product was lacking completely, so that's what we realized.

Speaker 1:

So then you started doing that. So what makes this such a different approach to cloud security? The way you think about, or you thought, or your company thought about cloud security.

Speaker 2:

Yeah. So the difference is, for example, as an attacker, if I'm trying to find exploitable issues in companies, I would look out for their public subdomains, domains, ip addresses, and then I am going to fingerprint how things are connected from outside, right in the company, without having access to any of the company's infrastructure. But then I realized that if I build a system which takes minimal read-only permission to your cloud infra and I'm able to predict the dots very precisely by having access to your cloud infra in a real only manner, then I could like create exploit paths which, as an attacker or and as a white attacker I was creating from outside yeah, and and to be clear, an exploit path is not the same as an attack path.

Speaker 2:

No, no Exploit path is you connect dots and then you actually send a harmless exploit from outside, like a whitehead hacker would do, and then you get the evidence. This is how you can be hacked from outside.

Speaker 1:

So every exploit path is an attack path, but, but, but, every so every, every exploit path is an attack path, but not every attack path is an exploit path.

Speaker 2:

Yeah, that's. I think that's a fair summary, a summary of this right.

Speaker 1:

Yes, um, so, and, and, and I mean that that would also probably mean that from what's coming in the SOCs and in the company's kind of organizations, right, yeah yeah, it helps you.

Speaker 2:

So I was a security engineer in one of the largest e-commerce companies in India very early engineer now valued around 60 billion, 50, 60 billion and we had this compliance thing and we were used to run the most famous vulnerability management tools which were out there and once a quarter I was given a report, a 2,000-page report, to filter out exploitable vulnerabilities in that 2,000 pages. This was in 2016. And so, over the period of time, I figured out that this is the real problem.

Speaker 1:

And we need to fix it Because probably, if you got a report like that nowadays, it would probably be not 2,000 pages but probably 6,000 or 8,000 pages.

Speaker 2:

Yeah, there are still tools which do it, and everyone yeah.

Speaker 1:

So then so exploit paths. How does that? So exploit paths? How does that I'm trying to get to? How mature is that right? How does it work in an organization? So, you have to trust, obviously, that what you find is actually well real and nothing else right. So these are the exploit paths that you use. What was the feedback from the market when you first introduced that to them?

Speaker 2:

Yeah, like very initially when I want to be honest here. So we went to CISOs and we were like we are going to send harmless payload to our environment to figure out stuff Like way early on, like 2019, 20. They were like this was very initial. Even the company was not even formed. They were like, no, it can cause issues and right, we want to do. You are not trusted, we want to do manually on our own right and we are okay, filtering out thousand page report and stuff. But when we put it on the POC, when we built it, cisos were amazed to see the results. We were able to cut a lot on the airbag bounty costs which they were paying out there, so much risk which they were paying out there, so much risk which they were like manually like cutting.

Speaker 1:

So how did you determine when something was an exploit path rather than just an attack path? Because that must be something that you got asked quite often as well, right? How do you know this is an exploit path and how severe is this? Was there also sort of a immediately some sort? Of a waiting or so a risk-based kind of approach? Was there also, sort of immediately, some sort of a waiting or a risk-based kind of approach to this? Yeah?

Speaker 2:

there is indeed a rating. So this is made possible by what we call our offensive security engine on the backend, which is a way of like safely sending exploits right and then we assign ratings to them based on the type of information that can be leaked from a specific exploit and the severities can be like low, medium, high, critical. If we are able to figure out that we are able to remotely execute code on a machine from outside, we mark it as like critical. If we are only able to disclose minimal information by sending that exploit, then we say that it's a low priority, it's not a P0 priority for the company and in fact, like we had customers who were using these traditional tools which are out there and we like ended up figuring out a lot many juicy stuff during the POC phase itself.

Speaker 1:

So basically, I think, if I remember correctly, you call this the offensive engine right that you use. Is that applicable to only cloud security, to CNAP, or is it also applicable to other areas of security? Can you see this being expanded more into other areas as well?

Speaker 2:

It can be expanded to on-prem machines as well. The only thing is you need to have some way to whitelist the offensive security engine so that it's able to scan things effectively. But it's like fully. It's like much more better when it's on cloud because it was built for cloud. But, definitely it can be even better for on-prem machines.

Speaker 1:

Yeah, because I mean I think that's a very important point you mentioned, because, at the end of the day, a lot of companies, estates are hybrid, right, so they're not only, and I mean you need to be able to see the exploit pass going in there or from there as well. So, but for now, it's only between quotation marks. It's already a big achievement, but it's only between quotation marks. It's already a big achievement, but it's only in the cloud environment, right.

Speaker 2:

Yeah, in the cloud environment. Plus, we have exploits on on-prem as well, but the company needs to. They need to whitelist scanners, so that's what we need.

Speaker 1:

And how do you see the cloud security market in general? Just out of curiosity, because it can be quite confusing.

Speaker 2:

It's very confusing.

Speaker 1:

If you're only looking at CNAPs for example not every CNAP is the same CNAP. No, Everybody has their own definition. But it's just sort of a buzzword. So people thought well, we have it too. But it's just sort of a buzzword, so people thought well, we have it too. How do you make sense of that world as a customer or as an organization?

Speaker 2:

Yeah, so I would put it in. So I was chatting with CISO a couple of months back and I was asking him why do you evaluate CNAP? So the problem was like CNAP has like multiple capabilities built in, like ASPM Kubernetes, security, Docker image scanning, IAC, secret scanning, CSPM, CWPP, the agent-led stuff, right.

Speaker 1:

A lot of acronyms.

Speaker 2:

Yeah, a lot of acronyms are there and the CISO was like I bought this product only for, like, my compliance reasons way early on, but I had to buy the full product Because there was no other way. So he was like I ended up buying the full product and during the evaluation he was more like every vendor is coming in giving me the same pitch, right, but some of uh, some of them are doing half baked, not in depth, right, and I'm not sure like what value I would get out of that, that particular product. So he was like I'm only looking to solve for compliance right now and maybe I would focus on other things because this is like mandatory, mandated by something, right. So I feel like it's confusing and, um, of course it's confusing for sure. And the real product it should have, ideally the exploitability. That's what I like thought when we built this company yeah, right, because that's how you help the.

Speaker 1:

You really help the teams which are out there who are struggling to triage these issues and prioritize these issues and something which could also like prevent things at runtime yeah so it's not like you can't go live without runtime, so runtime has to be there I think that's a that's an interesting point as well, because you mentioned in prevention yeah, because it's a lot of a lot of talk in in cyber is still is still is around detection and response, and obviously that's all very important, yeah, but prevention is also still extremely important and I feel like that it's coming back a little bit into the discussions. Is that your perception as well, that we're moving more again towards? Maybe we should prevent more instead of?

Speaker 2:

Yeah, we should prevent more for sure. And I will just share a simple example that we had. So we have very early in our product now we have like full-fledged remediation capabilities on CSPM side, but very early on we had.

Speaker 1:

And just to be clear, CSPM means Cloud Security Posture Manager. Right, yeah, for example, if someone opens up an S3 bucket like you fix it.

Speaker 2:

So we ended up so this was the most common problem across our customers where they were opening security groups and S3 buckets. This was the most common, famous, all the time. So what we did is we ended up adding a remediate button in our platform where, like, the remediation can be auto-triggered when a finding is there, or you can come to the dashboard and click remediation button and, to our surprise, most of our customers started using it very actively. It's more like in auto mode.

Speaker 1:

Oh really, yeah. So only two plugins. This was way earlier. Okay, because those are very confined, right.

Speaker 2:

Very confined, very well defined. This is what it does.

Speaker 1:

And then actually they want to use the automation, yeah.

Speaker 2:

So they basically used those two functionalities in the very beginning and what we saw is customers were really happy about it, because someone in the DevOps team or development team was opening up something and we were able to fix it like immediately within a second. Right, okay, yeah. So that was like super cool and they really liked it yeah.

Speaker 1:

But do they still like it when you do it on a larger scale? So these were just a couple of plugins, right, which are very well-defined, as we mentioned earlier. But when you have a complete platform or a complete CNAP kind of environment that does lots of auto-triggering stuff, that gets more opaque, right. It's not as transparent anymore. Do you see things moving in the right direction there as well?

Speaker 2:

Yes, yes, we see that and it depends on company to company like what all remediations they want to configure. But companies are very open about auto prevention and workload security as of today, like super comfortable. But on the CSPM side some of them are honestly still scared for low and medium ones. But I don't think like everyone would hesitate using fixing like security groups or s3 buckets like very automated in automated, because the problem is, if you don't fix it, the same IP address is going to be on short and maybe after 24 hours that opens you to everyone. If it's not in Shodan attackers, they would write scripts and they would get it within a few hours.

Speaker 1:

Finally, this round is off Going back to your beginnings as an ethical hacker or maybe somebody just wanted to make a buck and compare it to now, do you see? I mean we talked about the landscape has changed. It's harder to start now, but do you see that the market in general has learned from ethical hacking itself, so that all the easy mistakes are out? Of the infrastructure now.

Speaker 2:

Yeah.

Speaker 1:

Or do you still see some very, very, very amateur mistakes in cloud security?

Speaker 2:

So I think this depends on the geography. So we have some geography where cloud security is more mature. We have some geographies where, like, cloud is still getting adopted and you would, they would always do the same mistakes, right and we have some geographies which are up to some extent mature, but not that great. So I think it depends on the geography, on the geography. That's what I learned practically by traveling and meeting CISOs and security teams, because you can't really get exposure if you don't have cloud. If you are moving to cloud, you would end up doing the same mistake. There is going to be a learning curve and you end up fixing it, and the big tech players themselves.

Speaker 1:

You mentioned you found a bug in Facebook in 2009.

Speaker 2:

They are well aware.

Speaker 1:

Yeah, but there's probably still bugs.

Speaker 2:

Yeah, of course Every technology has bugs.

Speaker 1:

Whenever you develop something, you're also going to introduce bugs.

Speaker 2:

Yeah.

Speaker 1:

And they could even be the same ones.

Speaker 2:

Yeah, they couldn't be the same ones. Yeah, yeah.

Speaker 1:

And then finally, finally because we're out of time almost, I think what do you see in the near future for cloud security? What is it that you would like to be able to do from a cloud security standpoint that you can't do yet, but you really want to?

Speaker 2:

Yeah, I think the first one would be like innovate more and more on attacker-powered cloud security, and I think second would be the prevent mode Prevent things at runtime, prevent things when something happens, rather than fixing things manually after a day or two when you are compromised. So this is how the first one is going to remove the noise completely.

Speaker 1:

Yeah.

Speaker 2:

Yeah, for sure, right. And the second one combined with AI, of course.

Speaker 1:

Well, you also depend to a certain extent on what's happening in the market.

Speaker 2:

Yeah, of course, More broadly right.

Speaker 1:

So AI has an impact, but other maybe other developments in in cloud development or whatever can also impact what you, what you need to do. Right, yeah, to fix, but and those, those two things that you mentioned, they're also realistic, so it's just a matter of grind, grind and you will get there.

Speaker 2:

Yeah, okay, those are realistic.

Speaker 1:

So there's's enough in the works.

Speaker 2:

Yeah, okay.

Speaker 1:

All right. Well, I'd like to thank you for being on the show and I look forward to catching up again.

Speaker 2:

Thank you so much for having me here and it was great.