Ashish Rajan: [00:00:00] Welcome to cloud security podcast. My name is Ashish and today I have a really special guest welcome to 

Jay Kelath: okay. And thanks for the listeners, a great opportunity. So thanks for having me. Awesome. 

Ashish Rajan: How would you introduce yourselves to the audience who don’t know much about yourself? 

Jay Kelath: A security node file? 

I am responsible for our product security and Dow Jones have been instead of side. Both focused a lot more on the defense side of it. Security is fun with people learning new stuff. It’s all about the right now, as well 

Ashish Rajan: as give me, I think yeah, you put it quite well. Security is definitely fun. 

That’s all. We are here to share our knowledge as well. Have the show in like a few segments. And the first one is that on why and how the first question that I have is cloud security means. 

Jay Kelath: Security, a lot of things now that all the applications out in the cloud actually application security and cloud security as kind of mud fine, but product security data is in the stack from the stack. 

That is the cloud component. There is the application component cloud could mean should encompass. Like if you, if you think about as for instance cloud, is that application. No. Yeah, yeah, yeah. It’s, it’s very blurred. [00:01:00] And right now, and I think security as a whole is struggling with it too. 

Ashish Rajan: Support that. 

What about multicloud or the thing 

Jay Kelath: and clearly a thing we own. So we do have the cloud area, although we are mostly in AWS, significant amount coming up in Google. Okay. There’s some parts of it. And in Azure also, engineers are really picking and choosing between blood in different areas. Every was the thing that a DVP just for right now. 

Right. Azure has a lot of good things there around security engineers are kind of waking up to the fact that they can use clouds in different ways, depending on the product. 

Ashish Rajan: Part of the waking up to this reality that, oh, seems to be better at what a menu of different clouds you can go for, depending on what you want. 

I mean, for the hybrid world and as security people, like our security, this mean for us, people who have like no Dow Jones shore has a history. So a long list of data center. Well, I mean, for security doc, mighty cloud or cloud security hybrid, what does that mean for them? 

Jay Kelath: It makes our life a lot more difficult. 

It’s Dow Jones itself [00:02:00] since we have 80%, I would say in AWS. So we have put a lot of effort into duty tooling, building tools, et cetera for us. And we had to start doing similar stuff Google cloud, for instance, but that means building. T’s building up the tooling. It takes time and we are always on the back foot. 

And the same thing with Azure thing, you have applications, they are still kind of figuring out why don’t you do there? And so, a small team, like two or three people area, it’d be. Difficult to spread out and get the knowledge and then use that knowledge to, to build things that Kevin in farmers about what’s going on. 

Ashish Rajan: Did you say, oh, I guess in dental maturity dating, how do you guys rate yourself? Cause I know you’ve given a couple of talks as well as have, how do you and I, I, is it possible to rate the maturity of a platform? I guess that’s, that’s the first question. 

Jay Kelath: That’s something that I struggled with a lot. How do you manage. 

I haven’t figured out yet, things that think about from SDLC perspective, about how, how much security do you have pipeline. [00:03:00] You have a a pipeline at all, for instance to go cloud, then how do you start measuring these things in different worlds? And, so that’s something I haven’t figured out yet. 

It’s partly. 

Different different business unit becomes a talent. It’s not like we are focused on one area, have been a lot easier in my previous company where it is focused on one kind of business area. Right. So then you can 

Ashish Rajan: actually, you say, I guess, a good listening and are trying to measure that. So that was a baseline for it. 

Friendly security. What 

Jay Kelath: sports, the first thing in a DevOps world would be part of CICB pipeline. C I N C D is like the very stuff that we can build off of. And security can do that. If, if there is makes it easier for our teams to plug in in different ways. And those are the kinds of tools that we have. 

How do we plug into this? If you want to provide static code analysis, dynamic scanning and scanning, things like that gives us an opportunity to do that easily. So I think that would be 

Ashish Rajan: that’s sweet. So if anyone was listening, probably, SES in [00:04:00] the pipeline and is able to integrate security into it, that’s a good benchmark for. 

Your journey go about from, I guess, where you’ve been, you started in Dow Jones. How long have you been in jail for four years? Now, tell us about the journey that you’ve traveled in the four years and really start and very, very now 

Jay Kelath: the cloud journey at Dow Jones started way before I came on board. So I think Joan started about keen timeframe. 

Very early days came on board around 15, 16. A lot of applications in AWS already, but other governance, et cetera, as the timeframe, when things got a lot more serious and structured engineering, and I realized that we need governance, we need structure cannot have the kind of running around and deploying things. 

Right. So the initial state was kind of the lift and shift. Let’s get everything into the cloud. The realization that, Hey, maybe we should refactor some of these. And this is a lot more opportunity. We don’t have to do things. The hallway gives us a lot more opportunity. So that’s where is kind of sales to kind of make all of that a lot better. 

And the whole [00:05:00] DevOps thing started in honest in, it’s been about. Add, give us the opportunity to kind of go in and partner with them and say in the pipeline, we want things in the pipeline and we’ll help you build it where he worked with them pretty closely on one of the tools that we opened source called reaps are essentially plugging into the CACD Jenkins pipeline essentially kind of gave us the opportunity to it out tools like the SAS. 

Cases and all of that. So all of that into the pipeline made it CUNY team and easier. Probably a there’s two that you guys complaint that security team. You guys give us the parts that. Yeah, we cannot go through it. It’s it was a bad, are you 

Ashish Rajan: saying you cannot go to the 500 error messages that we just say you have switches to deploy 500 bugs in here, 

if you, at that point, that across already. So some interesting challenges as well. Okay. You are lightness. So you can get into a bit more of the challenges that you had in your initial. I guess how that progress, that would be amazing as well. 

Jay Kelath: Yeah, so we, we started off with, I kind of blame the vendors for this. 

Also we’ll have the security to link it. They always [00:06:00] tell you about, Hey, just plugging our tools into the pipeline that, and we failed spectacularly. So it was everybody hated us. We were breaking bills. 

Ashish Rajan: So, so you feel you failed because it was breaking mills or, or I guess what was the first approach? 

Like I just go with that. Right? So, so for those people who are listening to this may not have had any integration and probably are thinking of how they integrate. So some insight on when you went vendor basically said deploy that tool, all your buddies are gone. Yeah. Let’s start from there. What happens next? 

Jay Kelath: Did that the plugging into the pipeline? Well, you said was that the tour was not CACD friendly. We would have added scan, dynamic scan, et cetera, tools themselves. So like they, they, they would have a lot of false positives, first of all right. And the second thing is it would take way too long to run hard. 

Fake is the texts and things like that. That should have been naturally. They weren’t really. No, we did not turn on the break. The build the scenario, the build would break because the application cannot be contacted or all kinds of steps from 

Ashish Rajan: the developer application will break [00:07:00] not your application, I guess. 

Jay Kelath: No, the the, our application, the the tooling itself would break silently because of a lack of health checks and, and things. Three years ago. And I’m sure the tools have gotten better since then, but that’s the scenario that we faced initially. And, you know, we kind of build in the sense that the Jenkins job failed, because of our tooling. 

And of course people hate on it and, and we had to stop scanning and things like that. And. Our newest, especially we can say, you know, when you do something ad and we’ll stop trusting you, 

Ashish Rajan: probably the hardest thing to bring back as well. Right? Yeah. 

Jay Kelath: Trust is once you lose it. Oh. You know, do you in your, in your, in, in our pipelines go like 

Ashish Rajan: Jay again? 

Oh, no. 

Jay Kelath: Yeah, yeah. That guy. Yeah. So. We had to figure out what to do next and that kind of slowly built up this rapes are as easy to plug into the CI CD pipeline and arms, a lot of those, it abstracts away. I think it settles. Developers in a way that they are used to, like, we use JIRA internally. JIRA tickets is [00:08:00] the way that we communicate back and also through slack channels, et cetera. 

So that made it much more friendly and useful for. And we also kind of learned that we shouldn’t look for all kinds of vulnerabilities in the pipeline to oh, 

Ashish Rajan: okay. That’s an interesting one. So am I right in assuming the vendor product that you were using initially, you basically had find everything in the first bad idea when you launched started seeing that you losing trust with the developers, you switched over to another strategy, which is less focused on certain bugs or. 

Yeah. Like you had to go to the 500 error messages first and then kind of narrow down because I’m sure they would have been false positives in there. Yeah. 

Jay Kelath: Yeah. So we, we, we only look at a few things in the pipeline, things that are not false positives, like there are some that are, depending on the tool that is being used. 

There are vulnerabilities that have a high rate of false positives and others. You know, pretty good. So for example, there might be a.net and Java works really well again, or SQL [00:09:00] injection process scripting those kinds of technical vulnerabilities. Yeah. They don’t do really well with some other types of vulnerability. 

Lots of false positive happens with blind sequel injection and things of that nature. Right. So we just turned them off. So what we kind of say is that we look for. Things that are sure almost a hundred percent to be good in the pipeline. So that cuts down the number of vulnerabilities. And then the next thing we also do is to make sure that we that tests are run pretty quickly. 

Yeah. So incremental scans, et cetera. We kind of talk about 10% of the time to be spent in doing security. So it’s really defined the kind of the low-hanging fruit that we want. And then we’ll slowly expand that list of things that we find over 

Ashish Rajan: time because of the code base has been scanned for the obvious ones first, then, you know, for sure that okay, if those ones come again, I know the tool would just do it. 

Yeah, it’s the next ones that I need to go off. Let me just build some trust first, by going off to the [00:10:00] ones that I know are genuine. And did you have like a, like an application security person that being for this and did they play a role, like did an application security person play a role in this? And if they did, how 

Jay Kelath: yeah. 

They, the apps at PayPal definitely play a role in this in terms of. Defining, what do we, what do we need to look for? We do a lot of like manual pen testing and things like that on the side too. So all of that informs what goes into. CICB pipeline. We have our own internal kind of just like, oh, as fast as our top 10, we have the Dow Jones, top five, essentially. 

Right. And we are focused on driving that down. It’s really things that pop up again and again. And we want to find it, focus on that and then drive those kinds of vulnerabilities down. And then the next six months later, the list might be different. And then we’ll focus on something else. 

Ashish Rajan: Right. And how does this work in like a, I guess for example, you ran run the tool you find found a bug. 

What would that process look [00:11:00] like? Who are the people in board, like a developer or applications, or can you share that a bit as well? 

Jay Kelath: The app sec engineers, all the folks at the product security team are essentially application security folks. And we do have some contractors who work with us also just because of, you know, we don’t have the bandwidth to do all of this. 

So there is a, the. Part will be if, if there is a new code base, et cetera, and scans are done for, from a SAS and desk et cetera, then there is a person who actually takes a look at it and says, okay, these are false positive. These are not et cetera. And kind of making that initial list of like, what should we put into the CSED pipe? 

And what is the profile going to look like? What are the things we should check for? Things that are important from a application perspective, knowing the application and kind of figuring out what is important to that application and also getting the false positives down, to apply and where we can say, [00:12:00] okay, this is kind of that setup we are going to use for the pipeline. 

Ashish Rajan: I guess if I were to imagine this process and as a new product gets, I dunno, they’ll say let’s go make an example right now, just sinks under new product. And during the planning stage, would an AppSec person 

Jay Kelath: being all of the, kind of the important applications that are in use, they engage the application team or the AppSec team, very initially flat model phase and things like that. 

So there is. Type modeling that happens in the beginning. So we kind of know what the application is doing all of that. And then when it. Code comes up. It’s a little more easier to understand, then we have information already. Oh. 

Ashish Rajan: And do the engineering teams run track modeling sessions 

Jay Kelath: themselves? Not yet. 

So that’s a goal in our maturity curve. We have been focused on kind of the backside, which is the tooling and things like that. And we do participate in the threat modeling in the initial stage. Yeah. [00:13:00] But one of the goals this year is really to take that to the developers themselves. We have we are building up a security champions program and essentially we are training them to do. 

With some help from the app sec phone. So we’ll, we’ll never scale. Otherwise 

Ashish Rajan: the ratio of number of security people and number developers is always going to be a, well, it would never be fair. All the people might think it’s fair, but no, it wouldn’t be fair because where does security goes guys do right. 

All the above. Apart from being approved. 

Jay Kelath: Exactly. Yeah. Yeah. There’s just one year tools. Transom scans. Th that really kind of asked me quite a bit like, oh yeah, you just had to run some tools against. 

Ashish Rajan: Yeah. Yeah. That’s not, that’s not, that’s not the goal here, but obviously people don’t understand that because you said security champions would be taught, tread modeling for people don’t know what security champion is. 

And what does that mean and how does it go about doing it? And we’ve got some thoughts around that as well. 

Jay Kelath: Sure. Yeah. The. We have done here is to pick and choose a few people who are naturally interested in security. And [00:14:00] initially we came about this because of people reaching out to us developers who are curious about security, et cetera, they reached out to us. 

And so we started engaging with them and all the last couple of years we have, we have done things like CTF center, just fun things. Like we have made stickers and given things. Free staff, et cetera, things to get people more, more. And last year we did a CTF where we got a bunch of people you know, finding weatherability, et cetera, in the alas juice shop. 

Oh yeah. Yeah. We, we applied a bunch of them or, over the Christmas break and people are hacking away at it and Winners from different business units, et cetera. It was a core thing to do. So I think those are things that could kind of get security champion kind of people out into the open. So that, that helped us kind of identify different people, who are interested in not, not so much as doing security as a livelihood, but more as, Hey, it’s a cool thing I would like to learn and [00:15:00] hack on that. 

So we kind of nurture that. And all of that. So that’s, that’s another thing that we are very serious about doing is to get people. The different business unit and say, you know, Hey you guys, we trust you with the decisions you make. You don’t have to come to us for approvals all the time. If you are doing, let’s say you want to do authentication, we will talk about that the first time around, but you don’t have to come to us every time for. 

Yes. It’s your application. We trust you to do the right thing. We’ll teach you. And if it gets complicated, come to us, but not, we don’t want to be the rubber stamp. 

Ashish Rajan: That’s a good way to look at it. It’s an interesting one. Especially gaming security across multiple cloud is not easy. And I feel like just knowing one cloud itself becomes too much for one person sometimes based on the number of updates. 

Jay Kelath: Yeah, look at AWS. I don’t even know have to start with this that they had it’s actually. Yeah, 

Ashish Rajan: that’s right. And I believe the screen when they released some two 50 services again or something, and I’m like insane. This is one person cannot remember all of this to your point. Security has this challenge of not [00:16:00] only knowing one, but if an organization goes multicloud, you kind of have to be across all of them. 

Like we just talked about the three common ones right now, but they could be more. As far as competition comes in and we will say thing, oh, there’s more money in this. I’m going to stop non-public cloud service. So have you had some time to think about or share some insight on how do you see managing security across multiple. 

Jay Kelath: No, that’s, that’s something that we had to figure out pretty soon. There are the obvious principles, I would say things like identity and access management and things of that nature. Like everything has to be authenticated, authorized, log encrypted. So there is, there are those basic principles that come into play that we should definitely be looking at. 

Yeah. But all around beyond that I think it gets into a little bit of the nitty gritty details on how things work in those particular cloud. So, 

Ashish Rajan: yeah, and I feel this is kind of where the security champions kind of fill that gap as well. Right? Because you may be writing a security policy, which you want to [00:17:00] be across, say, Jeremy, let’s go dig encryption, right. 

To say encryption address everywhere. And the way AWS does it would be different to how GCP does it. It would be different to how. Azure does it, I don’t know if you may not even have the feature for it as well. You might have to request the feature. So it’s, it’s one of those ones where I feel security champions for that gap. 

You as a security person talking to a security champion, you can be asking that question then. Or how does this work in this. And yeah. Yeah. And put into the document. 

Jay Kelath: Yeah, that’s exactly right. Yeah. The, so we, we ran into a similar situation, where we had a bunch of code in GCP and you know secrets. 

How do you, how do you. Keeps secrets safe in DCP. We know how to do it in AWS. There’s a standard way to do it. But the security champion there, he figured it out. Like we didn’t have to, kind of, we work with him, but he is the one who figured it out and said, Hey, we should do. Oh, great. You know, and, and now, everybody is starting to do that. 

It’s a similar fashion. So that’s, that was what you said is exactly like, like we [00:18:00] have seen that happen in our environment. Oh, that’s awesome. 

Ashish Rajan: So switching gears a bit, right. I think we’ve, we’ve kind of spoken about engineers quite a bit. Switching gears, looking up the table, I guess in like for lack of a better word, how important is cloud security? 

From people who are business 

Jay Kelath: people, it’s a little bit of a split, I feel especially at Dow Jones. So you, the, the CTO, the CSO, the engineering leads, et cetera. Very very much into this. They know they understand, and they are making the investment into this. There’s a lot of money being put into it, people, et cetera, to do the right thing. 

So there is definitely that from that side of the world. Now, when you talk about the business side of the water, that’s something that, we are, we are starting to get some traction on. And part of the reason why. Is, I would kind of put the blame on ourselves and the security team’s about 50 it’s 50, 50 responsibility. 

Right. We need to educate non-technical, business owners about what some of these vulnerabilities mean to them. Why should they get, yeah. Why exactly, why should [00:19:00] that guy, like, what is, how does it matter in terms of money revenue that’s coming in. Things like that. So we, we have been so focused on the technology bit that we did not do the other messaging. 

Well. Yeah. And now we are learning kind of how to do that. It’s it’s a, it’s a big learning opportunity for us. How do you talk to a business person? Because it, ultimately, it comes down to. Like, why do we let hit the revenue? Like, should we fix this vulnerability? And if they had to make a decision, they need to know what the impact might be. 

Yup. 

Ashish Rajan: Yup. A hundred percent. It’s a good thing as well because the journey that you guys are on and good to good to know that there’s a lot of traction on the business side for cloud security as well. Cause I guess eventually when, when there is an incident, which we go into place. They probably have to face the music, I guess, and go in front of the press and talk about it as well. 

Right. Folks like us could be in the background. So yeah, it it’s, it’s an interesting one. I, I do want to switch gears. The, the second segment is offense versus defense. In the second [00:20:00] segment where we talk about is basically talk security incident. You were bought off. You’ve heard of that. You can share with them. 

It could not have been done by you, but something that you can share, for the audience. 

Jay Kelath: Sure. So about three years ago Dow Jones had a pretty public incident. It was in the papers, et cetera. And it, it was due to a key being leaked in an S3 bucket. Very. Lots of other companies have had the same issue also. 

And those kids want to and use to access the AWS environment and so forth. So resources in the AWS environment. So that kind of, that was a. Wake up call for all of us who are in the cloud, trying to do security in the cloud, et cetera, to kind of jump in and say, what should we do now? What should we do next? 

So that it doesn’t happen again. And, and our CSO and all of the exec, the upper management, what are the same thing? Right? We don’t, they are the ones who are on the front lines talking about this. And it’s a good, good story. So they’re asked for us was how do [00:21:00] you make sure that this kind of stuff doesn’t happen again? 

And if you, if you think about. Three four years ago. Now there weren’t a lot of tooling and controls and things like that, that existed. So we w w the first thing for us was to look at, Hey, are there tools that we can buy a pro Marty at the problem? Can we fix it? And it turned out that it did not quite work that way for our specific environment. 

And what really helped out was we used that incident to build our own tooling and we open-source that tool also it’s called hammer. And the, the good thing was that, how. Took this idea of, we don’t want to just detect issues, but we want to fix them in an automated fashion. And that it, it started with, public S3 buckets and so forth. 

And, and now it covers a whole lot of other things. But when you don’t have. To run around and fix things. This is a good way, like automatically I guess it, it’s kind of a DevSecOps way of doing things. It’s like, you find it, you fix it. Problem is,[00:22:00] so that’s, that’s kind of, that’s the good thing that we got. 

Incident and this whole, yeah. Yeah. And that’s helped kick off a lot of the other, things that we are working on this reaps our tool, or kind of came out of the same way of thinking that, Hey, we can automate a bunch of stuff. Now we are working on data governance tools to help protect our code base. 

And we’ll open source that soon also. So all of this is coming out of, we want to find stuff and fix whatever we can rather than. Just throwing it out to the fence to engineers or other people that fix it. 

Ashish Rajan: Yeah. Well, that’s a good approach and I think it’s more like security, the owning of this leaves and like, this is something we should be doing. 

So it’s good that there was a positive, there’s a silver lining to an incident three years ago and kind of worked out really well. You were able to contribute back and give back to the committee. A couple of open source tools as well, so that no one else gets to experience that same thing as you guys did, which is pretty great. 

That was a great answer to my question. The third segment, third segment is score mid busted. And the first question is what’s a common [00:23:00] McCloud security myth. 

Jay Kelath: Oh God. So many 

Ashish Rajan: saying my tool cannot solve all my problems. 

Jay Kelath: Yes. That’s the, I think that’s a fast. That was already tools out there. It’s like, it’s crazy bad. 

You got to out of say on any of these conferences, like, oh yeah, you use our tool. A lot of their problems are solved. Yeah. 

Ashish Rajan: I think people, but I think you and I spoke was offline as well. People kind of forget the people process part. And if you can share some insight on that would be amazing. Can I say someone who has gone to the journey over the past four years. 

Jay Kelath: Yeah. So I think from a so for you, if you take any of the tools that we have built, like reaps our hammer, et cetera. So I’ll take the example of ribs, and that the tool is the least interesting. The equation for me that we build a tour, it works, but it doesn’t really work without the, the process and the people, part of it, the process part was trying to figure out, we are only going to look at a few other abilities, and this is how we are going to engage with the developers through JIRA, through slack, et cetera. 

And, and things like that. So that [00:24:00] process piece was, is super important. I think that’s the cornerstone for it, for it being successful at Dow Jones. And then the people aspect is more around when we are giving people quick feedback, they can fix things when assets are kind of writing code or when the code is in their head. 

If you wait for a month, they’re already moved onto something. Yeah. And then the bug will sit around for awhile. Right. Who knows when they’ll fix it and then teaching people about cross-site scripting. Again and again, they will ultimately be like, ah, this is annoying. I need to learn how to fix it. One, one sentence. 

They’re sort of smart people and they’ll do anything to kind of not have that pain instant, like, ah, this is wrong. That is wrong. So if we can feed them the right info, then they’ll kind of look into that. So that’s why I say the tooling part is the least interesting part of it. You had to plug into the culture aspect of how the company functions. 

To get that process. Right. And the people part. Right. And that’s something that we don’t talk about. Like the, the blue team as a whole, [00:25:00] like we don’t, we never talk 

Ashish Rajan: about it. Yeah. And I think that’s a great point because people in process are probably 80% of the jobs and or vendors talk about that tooling. 

Oh yeah. It would solve a problem. It would solve a problem. If we can put it in money, it is not a problem for people. And process could be. That’s because all of this is pointless. If you can’t integrate that into an existing pipeline, or this is pointless. If it’s a tool is integrated, but people ignore the error messages coming up. 

Exactly. Yeah. Even more pointless error messages keep collecting backlog. And you’re like, what’s the point of this endless backlog. And then someone else walks in there’s this mountain of backlog Arab. From six months or seven months ago, it’s like you can keep kicking the can down the road, but for how far do you kick it? 

Yeah, I think we cannot as security folks, we kind of have to roll up our sleeves and like, okay, I need to do some, I’m gonna change my approach. And your point about. I feel, I think you’ve hit the nail on the head by the saying little work with the culture of the organization as a blue team, because as a blue team, who’s in the company, you know how your company works, you know who you need to champion to get them on board. 

You [00:26:00] know, the right people to talk to like no outside person can come in and not to point out our fee. It’s something that you have to work with your team as, as an and figure that out. Yeah. 

Jay Kelath: Yeah, exactly. It’s, it’s it’s different for every, every company that are, companies where, you know, they have, yeah. 

It’s there is no general advice, I guess, but just knowing, and that comes from talking to people who are spending time with them too. 

Ashish Rajan: The section, I don’t have a name for the section, basically. It’s basically a lutein wind segment. Okay. And if you can share a. For the audience for the blue team cause conserving I spoke earlier as well, Lutie one, four. 

She doesn’t have a platform to talk about a lot of things. We mean, we get a lot of platform to be a dag-gone by why didn’t we save money, save us from a breach, but we don’t get, talk about some of the wins. So keen to know if you have a win that you can share with the audience. 

Jay Kelath: Oh man. Let me see, like from a, from a tactical. 

View when would be the actual time it takes time to fix for bugs. So knowing that when we started. Doing all of this process, the, the time to fix [00:27:00] was in months, right? So you’d find a bug take many months to fix it. I had to chase down people, et cetera. And now with the, all the integrations that has gone down significantly, it is still a much longer. 

Then we like, but it’s still in, it’s in the same sprint or it happens in, in a couple of weeks. Yeah, so that the it’s a it’s, it’s getting shorter. And I think also the, the devs are getting better with with identifying these issues and not having them in the first place. So we don’t see a lot of, same kind of bugs. 

Coming up again and again, a lot of the the CACD staff that’d be that the bugs that we look at them as CSED pipeline, those are trending down. So then the new bugs are suddenly going down. So that’s a, that’s a tactical win from my view. Yeah. The, the kind of the whole overall strategic win I would say is with the security champions. 

People are. Kind of getting [00:28:00] are getting more interested in security and and they’re not looking at security as a blocker anymore. And they’re saying that, you know, it’s yeah, we need to take care of security, just like we do quality and performance. And, and this is where security just becomes another thing that that you look at. 

And I have to give a lot of props to. Our engineering leadership also because they have, they’re really kind of kept the message up the, with the CSO, the CTO, they have our bit like, yeah, you need to get security. You need time to work on security. You need time to fix bugs. So, it’s not a, it’s, it’s not because of. 

The security team doing it, but it’s, it’s been a, more of a collective effort so far cultural change. 

Ashish Rajan: It’s not just about, I guess a process as well. It’s about making it a culture. So anyone new coming in as well is like, oh, okay, this is how it works. 

Jay Kelath: Yeah, that is that. Yeah. We are, we are driving towards that. 

Like everybody talks about, you know, Google, Netflix culture and things like that. Right. It’s the [00:29:00] security culture is so much advanced or well so we, we, we want to get to that level where we are also, everybody thinks security is part of their daily. What. 

Ashish Rajan: To go into our next segment to the Ginny con segment. 

And this is basically, I guess what’s a superpower you have. 

Jay Kelath: So being a nerd is not as superpower, right? 

Ashish Rajan: This is a totally, 

Jay Kelath: so I I went to school to become an astronomer, fabulous. My chosen career path since, since I was like eight years old. And you know, I had made telescopes back in India and all of that, And then at some point after the PhD stuff, I realize that, oh, there is no money in, in any others that have no jobs even. 

And again, I fell into security, but security kind of affords the same problem-solving kind of skills, but I also do astronomy on the side doing some You know, Python programming and stuff like that. NASA has made a lot of public datasets from their image processing, et cetera. So that’s that’s something cool that everybody can do at home with a little bit of [00:30:00] Python programming and you can, you can find planets essentially. 

That’s what they want to use that data to score new planets. Yeah. Yeah. So it’s it’s, it’s cool to staff, anybody who has an interest in astronomy, you should definitely check it out. And NASA has made a ton of information, public, and citizen science is a big thing now. So I’m, I’m slowly getting into more of the astronomy stuff. 

Especially now that might not always, also interestingly. Oh, that’s right. Yeah, yeah, yeah, yeah. That would be awesome. Yeah, it’ll be kind of cool. I don’t add a planet or a comment or finding something unique. It would be cool. 

Ashish Rajan: Yeah. Yeah. And I want to move into the fun questions section, which is kind of towards the end. 

I like to ask people without any heads up on I guess you kind of answered the first question already, because I was gonna ask, where do you spend most time on when you’re not working on, on cloud security and product security? It sounds like is astronomy. 

Jay Kelath: Yeah, it is. It is a lot of it is astronomy. 

Ashish Rajan: Yeah, good segue into our next question as well. What is something that you’re proud of, which is not only a social on LinkedIn or Twitter? 

Jay Kelath: Oh man. I think the best [00:31:00] thing to see is the, the, the new security people who are coming up, the, the younger folks. Like helping them with kind of that, the right mindset, which in my case, it’s really about helping people. 

Right. It’s it’s getting away from the old school stuff about, you know, aha. I found badness in your, in your code. I can explain this and then run away. Yeah. That, that was what I grew up with. But. Getting people more into the mindset about, yeah. You found us, okay. Let’s figure out solutions and working together with them, make more of the people aspects of it. 

That has been rewarding for me. The, the few people that have here, kind of getting people into that direction. That’s been, that’s been a good. 

Ashish Rajan: Oh, cool. No, that’s, that’s a great one final question. What’s your favorite cuisine or restaurant that you can share? 

Jay Kelath: Cuisine is, I would say Indian cuisine, especially chicken biryani, 

Ashish Rajan: chicken Brioni. 

Jay Kelath: Yeah, hydro valley chicken, because that’s, whenever I go to an Indian restaurant, a [00:32:00] new Indian restaurant, that’s what I always get because it’s. It’s that kind of defines the restaurant for me. If they can do baby any good, then they can do anything else. 

Ashish Rajan: Even though it’s like eight 30 in the morning, for me, I’m feeling hungry for Brianna. 

Like I will, I wanted to end on a side. Different load was like, what do you see as a challenge for people? I guess we’re trying to start cloud security journey now, or I guess, is that a challenge that you see for them? Like 

Jay Kelath: yeah, the, the, I think that people and process part of it, don’t, don’t focus on the tools as much. 

I see that all the time. It’s, it’s always about the tools, but forget about how people actually build products. So yeah. Knowing how somebody builds products. And why is an important thing to understand before you talk about cloud security? If you want to set up. Identity and access management and governance. 

You need to understand what developers are doing. Otherwise it’ll just be like, they’ll, they are very smart and they’ll always find a way around the problem and do sort of shadow it stuff 

Ashish Rajan: as I call it. Shady [00:33:00] idea, I guess. Yeah, 

Jay Kelath: that’s a good one. I’m going to use that one 

Ashish Rajan: to use it. I use it everywhere. 

Jay Kelath: No, that’s it. That is the big thing is understand the people and process before tools. So think about why people might be doing certain things in a bad way, and providing that easy path. So if the secure path is the easiest path, then they will always. That’s, that’s what that’s, what I’ve seen in our environment is as soon as we kind of made it easy for them to detect and fix vulnerabilities and, you know, they, they do that. 

They don’t go around and disabled tools are, I don’t think like that. 

Ashish Rajan: So that’s a great way out. That’s a great point to end at this as well, but it’s in front of the positive note as well. So thank you so much for your time. Really appreciate it. And thanks for sharing all the knowledge of. I would put the tools in the show notes. 

If people want to reach out to you for further questions, where can they find you on what’s your socials? 

Jay Kelath: On, on Twitter, I’m on I met Kayla K E L a T H. LinkedIn. Just look for me Jakey lab. Yeah. 

Ashish Rajan: Thank you so [00:34:00] much. I appreciate it. Thanks. Yeah, 

Jay Kelath: thank you for having me. And yeah, I’ll be, I’ll be listening to your podcasts in the future and learning from other people too. 

There’s so much stuff to learn. Awesome. All right, bye. Bye.