Being A Cybersecurity Influencer And Finding Security Champions With Ashish Rajan

[00:00:15] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk is a dev-first security company, helping companies fix vulnerabilities in their open source components and containers, without slowing down development. To learn more, visit snyk.io.

Hello, and welcome back to another episode of The Secure Developer. On today's episode Guy Podjarny, President and Founder of Snyk, is joined by Ashish Rajan. Ashish has been described as a cybersecurity influencer and the best dressed cyber security person in the LinkedIn space by the community. Apart from being a global head of security for a forward-thinking product company in his nine-to-five, Ashish loves building communities by speaking and organizing meetups and conferences in the cybersecurity space. During COVID, he took this online and started a cloud security podcast, which currently is very close to hitting the 40,000-download mark. We hope you enjoy the conversation and don't forget to leave us a review on iTunes, if you enjoyed today's episode.

[INTERVIEW]

[00:01:38] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Today, we have a great guest who will give us a bit of a dual perspective here, both from an industry wide view, as well as his own role as Head of Security and Compliance at PageUp, which he does while doubling as the producer and host of The Cloud Security Podcast. I want to welcome Ashish Rajan to the podcast. Ashish, thanks for joining us here.

[00:02:00] Ashish Rajan: Thanks for having me, Guy. Very good to be here.

[00:02:02] Guy Podjarny: So, Ashish, before we dig in, I talked a little bit about where you are today. But tell us a bit more about what you're up to and what was the journey that got you to this spot?

[00:02:09] Ashish Rajan: Sure. I started off as any other person thinking security is pretty cool when you're hacking away, and I realized when my Hotmail account got compromised, like that kind of shows you my age as well. I was a bit devastated that my Hotmail account got hacked, and I wanted to find out everything about how to not get hacked, which led to a journey where I tried getting the academy qualification for it, went down the path of doing a Bachelor's and did a  Master's in Information Security. But definitely wasn't anywhere close to where I wanted to be, where I could think I could keep my Hotmail account safe. Not that I have that anymore, in case anyone's wondering.

I've gone beyond it and my first job was basically trying to do pen testing. I hated that first month. I realized quickly, I am not someone who can read through a manual for hours. So, I switched gears and switched over to identity access management, which became my first entry into blue team. I did that for a couple of years, moved on to a security architecture role, and became part of a startup based out of Melbourne, Australia, where I helped grow our security practice. I think we grew the company from – we were 10 people, we grew up to about 300 and had about 20 people in security. So, that was great.

I did about Cloud migration and my team helped do identity and access management and cloud migration in a proper way for a lot of enterprise companies, which included bank, telecom companies and everything. That was my stint into Cloud. As I was kind of going through it, I kind of realized no one is talking about cloud security and the person that I am, always trying to look for, “Hey, what else I could be doing?” I decided to start a podcast called Cloud Security Podcast, which is kind of coincided around the same time that COVID happened because I was stuck at home. I was looking for content that I could consume myself while I was getting bored at home. I did sort of end up “well, no one has it, might as well create one.” That seems to have done well. It's been just over a year. We've kind of finished, now we have about 40,000 downloads that we get. So, it's pretty good. That's become my non nine to five. After I completed, I guess, my tenure at the previous startup, I got my exit and I started working as a head of security for a company called PageUp, which is a global recruitment software with offices in US, UK, Ireland, Singapore, Asia, Australia, New Zealand. So, yeah, that's kind of how I ended up in a very brief version.

[00:04:33] Guy Podjarny: I mean, it's an interesting journey to it. I don't know how many people would sort of point out to sort of reading the manual being a necessity. In pen testing, I think for a lot of people, it's about finding – I guess it's read the manual to sort of find the gaps.

[00:04:48] Ashish Rajan: Yeah, I feel definitely I was under the misconception that when they show you in movies that this is a writer tool, and it just happens. While the reality in most cases, I'm sure you'll agree with this, even when people give talks about, say something that we know in reality takes years or maybe months to achieve, in a video or in a movie it happens in five seconds. It kind of gives a false assumption that it only takes five seconds for me to hack into something, I can hack into NASA in five seconds, because I just need this tool. Never happens.

[00:05:17] Guy Podjarny: Yep, not quite. Let’s maybe journey a bit, look at PageUp first, and then kind of expand into sort of the broader world of community. So, tell us a bit about PageUp and your kind of security practice over there.

[00:05:28] Ashish Rajan: Sure, I started off and, funny enough, I was one of the first remote hires for PageUp. This was mid pandemic when we started. Melbourne was in complete lockdown. So, I only managed to see my boss after eight, nine months of actually starting with the company. That was for Christmas holidays, by the way. So, I started my role somewhere around early 2020. I only saw my team, my boss and the rest of the organization, well some of the people in the organization only towards Christmas of late 2020. As a company, PageUp helps – so, every time you go on a profile, I guess you apply for a job, and you click on the Apply button. That system is usually called like an HRIS system or UTMB from the HR world. That's basically a SaaS service that you can use to apply for a job.

As someone who's advertising for a job, I can manage applications coming in. So, one of the things that I looked at from a security perspective starting off new - a couple of challenges stood out for me. I want to understand what the culture of the organization is in terms of how open are they for security changes? Would I recommend something and that just be shut down? Fortunately, that wasn't the case. I was good. The other thing that I was looking for is how do I build trust in an organization when I haven't met anyone in person? Because there's usually for people who probably who may have not started remotely would remember their first year in office where you go and everyone say, “Hey, this is Ashish. He's a new head of security.” You say hello, you do a meet and greet. They officially know you as a person so you can reach out to them.

But when you're working remotely, is this person for real or is he trying to scam me? He’s in the computer network. But I guess he's true. This is what's going in my head. I'm fairly sure the other side is not thinking about this, but this is going in my head. How do I validate that I am who I am saying I am? So, those were some of the things that I looked at in the beginning from security. But fast forward to today, I've been fortunate to be part of a company where we do deploy two or three times a day, we have CICD. We actually, funny enough, have implemented software composition analysis as well. It's really interesting how it was possible even in remote format, you realize the culture, like certain things that you do. and the responses that people give you kind of makes you feel, “Oh, actually the company does believe in security and they do go a long way in supporting initiative, even though they've never met me in real life.” Which is a good thing, I guess.

[00:07:46] Guy Podjarny: Yeah, the company sounds like it was remote in the first place. Right? You were maybe a little bit more distant, but it has –

[00:07:52] Ashish Rajan: So, the ****company was never remote in the first place. They have a Melbourne head office. So, I'm in Melbourne, and we have a head office here with three floors full with people. I think a –

[00:08:06] Guy Podjarny: Never got a chance to meet them.

[00:08:07] Ashish Rajan: No. Never. So, I think it's like a week before I accepted the role or when my final interview happened, Melbourne went into complete lockdown. No one was supposed to come into the office. We had this five kilometer or three mile radius that you can't leave beyond. So, there was no way anyone is going to the office. Yeah, that kind of limited the possibility of meeting anywhere remotely. So, we became a remote organization after that.

[00:08:30] Guy Podjarny: Got it. So, what were some of the tricks? I mean, when you think about what worked and didn't work as you were trying to prove your validity to the org? Are there are some techniques that you'd kind of recommend repeating for someone in a similar state?

[00:08:43] Ashish Rajan: Yeah, yeah, sure. I think one of the ways that I did the trust model was a lot of people were going – I’m sure some people in the UK and otherwise are still in lockdown. Some people are still working from home and continue to work from home. Some of the things that I tried and this was my thinking, was how do I build trust in people who have never met me and I use the same approach that newsreaders do, which is if you see them on video enough times you start trusting the person, that person may be lying to you. Not that I'm saying I'm lying. But it's the same concept where if you see someone enough times at different locations, you start trusting the person and that's just a human design. It's not a trickery of some sort. That kind of gives you that first level of, “Oh, I know this person.”

I never brought up security in the first conversation. The first conversation was always “Hey, I'm the new guy, trying to understand what you do for the business, what’s your role in the organization, how has security worked for you in the past?” So that was kind of like the first couple of weeks and it was really interesting to hear, I guess the different viewpoint everyone had about security. So, one of the things that became, I guess, one of the things that I'm working towards is like how do I unify that view? So, say if you were to kind of reach out to PageUp and talk about, “Hey, who's the security person for you guys?” At least they are aware of who the security person is and they are also aware of, I guess the kind of common security things we come across in PageUp.

That was kind of the two things that I wanted to dive myself into. The first one, I started attending events, which were taking place in PageUp. We have like a weekly company update. I made sure I was hosting a few of those. It was a bit daunting to have over 150 people on a one video call, but I think I survived the few times I did it. The other thing that I did was ever, I guess, a lot of people may be doing this in the companies where you might have some kind of like a mindfulness session or some form of, “Hey, let's learn something together remotely, while we stay positive.”

I ran a couple for security over there, not from a security perspective that, “Hey, you should do static code analysis or software composition analysis”, but with more in terms of, “Hey, all of us are working from home, our kids may be using the same laptop, which maybe belongs to the company, how do we ensure that they use internet safely, you're modems are secure...” – and it’s more like going into complicated. “You should install the software” is more in conversation that, “Hey, when you go on, say a road trip somewhere, you normally have those stop signs, and warning ahead, there is an accident. There's nothing like that for the internet.” Relaying that message for the parents so they'll feel safe themselves and at the same time, they’re able to learn something that they can do for their kids as well.

That was kind of like the first couple of things that I did. And well, I'm going to keep the second half short, the conversation with developers became, I had to identify the tech leads, who were running the projects, how do they engage with security, what they already doing something in security, because based on my previous interaction in the 30 companies that I've helped move into cloud, and by the way, PageUp is completely multicloud, for lack of a better word. It was really interesting to hear how people approach security in their own way. I'm surprised how unified the view was in PageUp.

Going back with my previous experience, where if you talk to one department, the other person doesn't know how the other person does security. So that was surprising for me. It sounds like I'm drinking the Kool Aid, but this is obviously one year in the job and either they have been hiding the real picture because it's all remote or it's been good so far.

[00:12:20] Guy Podjarny: Yeah. I don't think it's just Kool Aid. I mean, I think it sounds like you were maybe the first, or were you the first security hire? The first person with security in their title?

[00:12:27] Ashish Rajan: No, third hire. So, there's been two more people before me. Yeah, but I guess I was the best one, I guess.

[00:12:37] Guy Podjarny: Sometimes when sort of the culture cares about security, you know, whether they unify it or not, that's the way you survive to more people. How many people were in the company by the time you joined? I’m always curious about hiring..

[00:12:49] Ashish Rajan: I think we were 250, I think. I don’t know the exact number. It’s going to be a trick question. Yeah, I think probably 250 Plus, I want to say, but 250 Plus, I may be wrong. I will say 250 to 500, because I need to go to LinkedIn and find out how many employees are there. But number of developers, 100 plus for sure. Around the hundred developer mark. Yeah, let’s just go with that.

[00:13:08] Guy Podjarny: It sounds like you're just sort of you know, it's really about human interactions that sort of drove a lot of that initial trust. And indeed, I guess, thinking about the dev side a bit more. How did you approach coming in, you're trying to understand, you know, what's the current state of affairs in terms of security practices, security tooling, security mindfulness amidst development? How do you approach this? How did you decide what to do first, and then what were those some of these first steps?

[00:13:35] Ashish Rajan: Something that I had success with in the past when certain enterprises was running a security champions program. I kind of used that as an opportunity to – the way I approached it was we use Slack for communication and every now and then you would hear about Capture the Flag events that happened. I think most training programs have these. Some of them are free. Some of them are, I guess, paid for. What I started doing was just to fish out the security champions, I started posting about that on some of the channels for the developers hanging out.

I would say, “Hey, I'm doing this capture the flag. If anyone's keen, I'm going to run a PageUp team for it as well.” I was really intrigued – I think I had about 10 people who fit into that. It was a trick, but it was just to weed out the ones who are inclined for, “Hey, what is this thing?” And as you talk to them, you realize, actually, they do have a security inclination like, not that I'm saying they should change their job to security, but more the fact that when they look at a problem, they do have security in mind and that to me is a security champion, not someone who's doing full-time security, I guess.

I don't know if that's how everyone else looks at it. But my personal viewpoint on security champions is that there are people who would be the regular Joe's of the world in a development world, but when they look at a problem, they also look at that as, “Hey, how do I secure this? Why do I need SSL? Why am I doing software composition analysis? Like what's the point of that?”

But without me even saying that, they’re already aware, “Hey, I'm running dependent board, and I'm doing all this.” All right, very interesting. So that was a way for me to weed out the security champions and that was, I guess – I unofficially started a program called security champions. The channel is also called Unofficial Security Champions. I introduced the concept to everyone and I said, “Hey, this is how I am going to approach it.” And everyone is happy with the idea. Obviously, in previous companies, it was obviously like a different stage. So, we had training programs and everything. This is the beginning of it. I've been running it for at least six months now. I've been in the role for one year, but I've been running it for six months now.

It's been really interesting when people reach out and, “Hey, I'm seeing this. Do you think this is right? Can someone from your team help me out?” I think that has been my approach with most of the dev, I guess, the security mindset. And they've been helping me driving and asking the questions in their teams, which has been the approach so far, and I get almost kind of like a zoomed-out view from whenever I do catch up with them. That's been my approach, at least for now, seems to work.

[00:16:03] Guy Podjarny: Yeah, I love the sort of 'lure them in with the capture the flag' type element, just sort of have people basically self-select into it. In your mind, what would tip the balance between an unofficial security champions program to an official security champions program?

[00:16:23] Ashish Rajan: Yeah, it’s funny because I named it unofficial as a fun thing and because I think the official – well, the CEO is aware of it. So, it's kind of official, but not official. But something that tips over for me is when we have like a proper program for helping them train in different languages as well, like, how do I do secure coding in Node.js versus something else. I think, when it's a proper established program, like that support system is beyond just, “Hey, I'm trying to solve this problem. Or we have a certain tool that we want to use, help me implement this, because this is how it would improve our security posture.” I think it's more of a feedback loop kind of grows and they have a bit more training program. At least, that's how far I've gotten with it.

For me, the tipping program would be being able to bring some more money into it and having some training for where they want to be trained in.  I've got people who are interested in develop – they want to understand what secure coding practice looks like. And I'm working with certain programs and roll them in. But once I start doing that, I think that's the point that I would start saying it's an official program. I feel like training is important because Google can be a bit – it could be like finding a needle in a haystack.

Everyone has an opinion, everyone has a blog, and the last thing I would want is for them to do their own blog and get the wrong information and copy paste that in. So, from that perspective, I trust a recognized program is probably a better start. So that's when I would make it official, I guess. For me, that's the tipping point.

[00:17:56] Guy Podjarny: It’s good. I mean, the evolution. I like the unofficial. It’s a bit of a probably less scary program for people to feel like they're a part of it [inaudible 00:18:04].

[00:18:05] Ashish Rajan: It doesn't sound like a full-time job. If I say security programs, it’s like, I guess, how do I take our time for this? Which I used to find in my previous engagement, like how do I take out time from building features versus spending time on this.

[00:18:19] Guy Podjarny: So, if we continue down that journey, so you came in, you establish trust, you identify your sort of champions and allies in it, how do you decide what to do first? Where to focus in and what to build, or what security improvements?

[00:18:34] Ashish Rajan: One of the things that came out of the conversations as I was going through, and this is probably the same across the board, in respect of the size of the company that you may see. In my experience, has been the fact that software development lifecycle and operation like the broader security, I kind of look at product security as a whole, which has almost for me, it has two components. One is the application security side, and one is the platform security side. So, the two platforms, takes from a platform perspective, there's a lot more experience, and there was a lot more, I guess, because coming from a traditional data center world is 15 plus year-old company. So, they've migrated from data centers to the cloud. They're fully cloud now, multicloud now as well. So, it almost goes to the point that, “Oh, okay, so you've kind of transformed yourself the right way into cloud. But I guess where do you start from security.”

There are almost like two pieces of work that we started off with. One was, I guess, reviewing, doing an assessment of what we have and our cloud service providers. The other one on the other side was we were using dependent board at places. But I think the version we were dealing with in terms of the languages that we dealt with, were not always covered with Dependabot, so there was a bit of a challenge there. In my experience, I've always found software composition to be an easier way to start having conversations in security without scaring them. My previous experience with static code analysis hasn't been great. I did the sin of sending the report or at least my team did. They did the sin of reporting, sending the report as it came out of the tool straight to the developer. That's like, we're talking 30,000 alerts out of which only five were relevant after you kind of comb through it. But obviously, we didn't do that job and we sent 30,000. I never heard back from that development team again.

I decided to learn that lesson and not do that and repeat myself. So, software composition analysis has been my favorite since then. I've kind of gone down that path. It's an easy one, because it's not scary because most people are not looking at thousands of repos. They’re usually just looking at three to four at max, depending on the size of the organization. Obviously, some organizations have a lot of a larger stream of work. So, they would have a lot more repos. But most teams are like the pizza sized teams that Amazon has been recommending. So, the software composition analysis definitely works. Static code analysis definitely does not work.

While I'm on the static analysis, I would definitely add, I feel that is a field, it may come across as a controversial thing, but I definitely feel as a field, it's either going to disappear, or it's going to mutate out. The reason I say this is because you look at this from perspective of GitHub is integrating code scanning in their product. If I'm committing my code into GitHub, why am I going to send it to another provider to get another analysis done when I can just do it in GitHub? And then some providers have started doing it and the ID directly. Why would I do it at GitHub if I can do it in ID?

You can kind of see that static knows what you're talking about, static code analysis. People start talking about, I'm already on the left, I'm already doing it in the ID, I'm already doing in GitHub, and I commit or GitLab from commit. So, why do I need to run a third round of static code analysis using this tool that he recommended? So, I personally feel as a field, it may potentially disappear, for like forever, and people are going to send me hate mails after this. But you will say this has been a prophecy.

[00:21:55] Guy Podjarny: Yeah, the way it's currently working is broken, it's flawed. I'll throw in a small plug to sort of see if we managed to make a bit of a dent of this with Snyk code that will become freemium in a couple of weeks, while maybe actually around the time that it sort of runs out. Fundamentally, it's become the poster child of how not to engage developers in security because it is slow. It's sort of riddled with false positives. And so, the signal to noise is just such that it's not useful. So, I'm totally with you.

I've personally built a static analysis product in AppScan, AppScan Developer Edition that we acquired out. I was at IBM at the time. When I started Snyk, the whole, the thesis was, we're not going into static analysis. To get into that world, we need to reinvent, invent some new math, because there's something different that you know, a fundamental problem is there and I'm as biased as they come and apologies for the self-promotion here. But the deep code acquisition we did last year, I think that those guys invented some new math on it. So, time will tell.

[00:22:50] Ashish Rajan: I'm happy to be wrong. Don't get me wrong, I'm pretty sure it does a good job. But in the current standing –

[00:22:54] Guy Podjarny: Yeah, and it fits in my opinion, it fits your description of like, it has to mutate substantially, like it has to look very, very different than what it looks like today.

[00:23:02] Ashish Rajan: It has to, yeah.

[00:23:03] Guy Podjarny: Because the way it works today just doesn't work.

[00:23:06] Ashish Rajan: I feel static code analysis is the reason why a lot of people started saying security is a big no. It is more than firewalls, it’s more than any of this, is static code analysis because you just throw it over the fence and good luck. You're like, “Well, no wonder developers will hate you, because you tell them you can't go into production until you solve all these 300 false positives. But you haven't put the effort to resolve or at least comb through three hundred false positives to just the five that are relevant. So, I'm with you on that one.

I'm looking forward to that for now. So, it'll be really interesting when it comes out. Because we already use Snyk as well. So, it'd be really awesome to see that.

[00:23:38] Guy Podjarny: It's worth trying out and you know, hopefully we get it right. If I go back a little bit out of that sort of the SaaS tangent that we get into, I like if I go back, I like the approach, which is it's really about finding early wins, right? You're sort of going down the path of sort of software composition analysis, feeling which, I relate to. Nobody believes me because it sounds self-serving in the context of Snyk. But SaaS is an easier way to sort of endear yourself on development, get them used to doing an initial security muscle. So, I like that. So, you find those opportunities, and then you kind of grow from there.

I love the journey and I'm while I'm kind of interested in sort of thinking more of how that evolved. I'd also love to pick your brain a bit on what you're saying broader. So, this is been kind of your first year, and building those out. But you've also been building the Cloud Security Podcast and having conversations with leaders in the space. So, looking over the course of the year, like what would you say are the main topics that are on people's mind? And maybe even, is that the same through the year? Or do you feel like at the beginning, you get different topics that people were bothered by then in recent months?

[00:24:39] Ashish Rajan: Yep, for sure. So, 2020 when I was starting the podcast, I was still talking to a lot of people who were still learning about migrating to cloud. A lot of those conversations around, “Hey, I'm going to migrate to cloud.” It's been like seven, eight years. Why are you guys still migrating or thinking of migrating? As I dwelled a bit deeper into it, I kind of realized that most of them were from DOD or I get some government organizations, so they obviously had – they were late bloomers for lack of a better word. I support customers spread across most of the US, as well as UK and Australia, what I realized from the conversations across Australia was more around, we were kind of like the – so I don't know if you know this, but apparently until like a couple of years ago, Australia was the largest consumer of Amazon Web Services outside of the US. I don't know if it's still the case. But it was really interesting to hear from their perspective that Australia was a lot more mature in terms of how to migrate into cloud followed closely by UK and Ireland, the EMEA region, I think that's what they call it.

What I found really interesting from an overall theme conversation was people were initially confusing cloud security with application security, which is not. For me, cloud security and one of the guests actually said it right. They said, people [inaudible 00:25:54], it’s AWS, it’s Azure, it’s Google Cloud, but at the end of the day, it's still a data center, it just happens to be called Amazon or Google or Azure. From your lens is just another data center. It doesn't matter where it is. If you want to connect Amazon to your local data center or Azure, you just connect them together, whatever. But I think the overall themes that came out of that this year has been so far, Kubernetes is definitely like, oh my god, like the amount of questions that I get for Kubernetes to the point that I'm doing a whole month of Kubernetes in May.

The other one that I'm getting a lot of questions around is Google Cloud and bug bounty in Google Cloud space. Because for some reason, Google Cloud has been really popular in the big data space. But they have a really popular bug bounty program as well that they've been giving thousands of dollars away that no one talks about. Bug bounty is another topic that people jump on to now when they finish off uni, like what do I want to do? I want to be a bug bounty hunter. From pen testing, you’re a bug bounty hunter, because you see all the people on Twitter – well, not the people - the kids on Twitter, driving the Mercedes, and you're like, “Wow, I want to be like this kid. But I'm only 15.” They're the ones who are basically going down the path of bug bounty. So, they've been asking a lot about that.

The third thing that I've been noticing is, for lack of a better word, I get a lot of people asking on how to go down the path of cloud security architecture roles, or cloud secure engineer roles. And slowly there is almost like a separation that's coming between cloud security and application security. People are realizing, “Okay, so when I'm talking about application security, I'm referring to infrastructure, or I'm talking about serverless. I’m talking about compute.” I'm not talking about “how do I do static analysis?” or “how do I do software composition?” That's completely different.

Initially, people were just putting that in the same bracket. Like, that's never been the case. So, this year, I feel there's a lot more maturity. But in terms of teams, because now people are realizing, “This is compute, that’s where cloud security is, it’s more around Kubernetes, containers, serverless.” They're definitely the hot topics, like most of my episodes, I probably had, still had the most downloads on it. And the questions have been primarily around how to get more talent into the cloud space, which the cloud providers are doing a great job of.

[00:28:11] Guy Podjarny: A lot of insights of what’s happening. I'd love to kind of unravel a bit the cloud security versus application security, how much do you think that statement, that sort of cloud security is so different than application security is short lived? On one hand, it clearly shares a lot of the security concerns of the data center of old and it's just sort of in the cloud. But on the other hand, a lot of the practices around kind of cloud native development move in the infrastructure concerns with terraform files or Helm charts or whatever they are sitting in a repo edited, oftentimes by the very same developer, writing kind of the custom code. How much do you think the separation of cloud security and application security, or maybe what bits of it are today versus which ones are, but will change over time in and will become more application security versus which aspects, if any are?

[00:29:03] Ashish Rajan: That's a good question, because I definitely feel that as compute is moving more towards serverless, cloud security is becoming more about identity and roles and access. So, if I were to use an example of serverless architecture, most of your focus is around the peripherals on, “Hey, how does Guy access serverless? Can he upload files? Can he do encryption?” But it's definitely not around the package that you're uploading or the function you're uploading as a serverless function to run. At least in my opinion, that still would be at least for 2021 and 2022, I think unless something dramatically changes, there will still be that line. The only reason why the compute pieces have gone down the serverless path is because I guess it's a popular theme in the industry that security is [inaudible 00:29:56] so let's take away as many controls as we can from them.

Well, with security, we will talk about usually in data centers, they talk about patching. Well, serverless, you don't need to patch because you don't own the compute, you just give it the function, it just runs it. The same goes for scaling, or availability and all that as well. Serverless will take care of that. So as people are progressing towards serverless, the function of cloud security is kind of reducing down to more identity and access management, and the usual suspects of key management encryption. If I'm a developer in Lambda, or any of the serverless functions, my concern is job just or if I say application security, I'm just looking at the code being uploaded. There's still a delineation there. I don't see that delineation go away.

I'll give another example on this. When cloud kind of came in to become what it is today, where we were all about empowering developers, what we kind of didn't talk about was the fact that developers whenever, I guess, sysadmins to begin with, they were always developing a program, they're solving a problem, right? They were never building, I guess, infrastructure to solve a problem. It was always, “Hey, this is Joe down the road”, or “Joe in sysadmin building”, just go up to him or her and tell them I need 11 servers by six months period. That's where we all started, at least I started a waterfall methodology and all that.

As it has kind of evolved, we've kind of tried giving some of the power back to the developers. But unfortunately, the education system hasn't really gone into that phase where, “Hey, now you should know infrastructure.” But how many developers do you know out there who would claim to be full stack developers? Full stack development in my head is like you know how to deploy in a cloud service as well as you know how to program really well. There are not that many. People claim to be full stack developers. But if you've gone to the nitty gritty of it, they've done one cloud native piece, but the other one, not really. So, I definitely feel it's the same with cloud security and application security as well. There will be people who would claim to be, “Oh, I know both.” But I definitely feel there would be use case for having application security separate to a cloud security. Cloud security may itself reduce down to identity and access management, unfortunately, or fortunately, I guess, because for security, then they don't have to worry about this thing at all, let everything be application security problem. But that thing would continue to be there though.

[00:32:16] Guy Podjarny: I think that delineation or sort of that figuring out those lines is going to be a key topic in the coming years. Because I don't know exactly what sort of cloud security will sort of form over time, but it probably wouldn't look like it is today. because fundamentally, I think the force that we all just need to accept is the move to independent teams is sort of the desire to sort of have these application teams and development teams run without needing to depend on sort of someone external, who can never really keep up. And so, the question is, like, how does that really ever come to fore? Because you're also correct that developers are, the answer can't be developers just need to be proficient and amazing at everything as they're doing and [inaudible 00:32:54] of appsec people. So, it'll be just interesting to explore that change as it moves along.

[00:33:00] Ashish Rajan: I think this is how you land on position descriptions, where they asked for a CISSP for a junior analyst position, because everyone's unicorn. So then you have a full stack developer requirement for – you know there is not many full stack developers, but you always hire for a full stack developer, knowing so well, that the person is probably a good developer more than a full stack person who just happens to have done a few things. That's my opinion on it.

[00:33:22] Guy Podjarny: But it's a very fair and correct point and we all want those unicorns, I guess, kind of as vendors or sort of as tool providers in the space. The job is to simplify and kind of make it reasonable for someone who isn't an expert.

I guess before I part ways, the conversation has been great. And again, we probably could have dug into each of these topics for extended periods of time. But before I let you go here, if you took out your kind of crystal ball, and you thought five years out someone doing your job as it is today, what do you think would be most different around their their surroundings, the reality, the problems or opportunities they face?

[00:33:59] Ashish Rajan: Funny. Depending on if they're in cloud. I definitely feel the job would be a lot more different. I think I definitely feel security as a team should try and do enough automation that they can get themselves out of a job. So, all of us can start working towards AI and ML, instead of trying to still solve patching problems. But if I had a crystal ball, that's where I would see the future would be where someone like who's probably the head of security or CSO is trying to solve AI and ML problems or using AI and ML to solve security problems. Instead of we have a lot of data, which we've been consuming for so long or in terms of creating chord, in terms of generating security events. How do I make sense of that in a way that it makes sense? And not the drinking Kool Aid kind of way where everyone says they're doing AI and ML, but what they're really doing is pattern matching. And it's completely fine to call pattern matching, but it sounds much more nicer if you say AI and ML. So, I would love for security to be kind of going down that path as well as developers leading that race with, they seem to have a lot more evolved AI and ML programs than what we do. But I definitely see this already happening in Netflix and other places as well.

So, at least from the guys that I spoke to in Netflix, it seems like they've hired data scientists and they're already going down that path already. So, I would love for more security and someone, I guess, Ashish in five years to be possibly solving that problem for a much bigger organization as well.

[00:35:23] Guy Podjarny: That's a powerful destination there. So hopefully, it comes to fore. Ashish, thanks for coming on the show. This has been a great conversation.

[00:35:29] Ashish Rajan: No problem. Thanks for having me. I appreciate it.

[00:35:31] Guy Podjarny: Thanks everybody for tuning in and I hope you join us for the next one.

[END OF INTERVIEW]

[00:35:38] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don't forget to leave us a review on iTunes if you enjoyed today's episode.

Bye for now.

[END]