Tejpal: For the Boy Scouts, that's a very interesting phase of my life. My son is now graduated. He got the Eagle Scout, which I'm always proud of him, but I also find that is a good outlet. Boy Scouts is a very good outlet for parents to learn along with their kids. So, while my son was in the Boy Scouts earning his merit badge, but I was always helping him how to, you know, do the ski, or do the camping, and what challenges you can have during the camping, or how to set up the tent for an example. But at the same time, how to build leadership within the kids, right? How to talk, and how to interact, and how to bring the synergy with other kids. So, it's also another outlet, which really I'm always thankful to Boy Scouts because, indirectly, my son was in the Boy Scouts. Along the way, I was also learning a lot from the Boy Scouts.
Caroline: Welcome to "Humans of InfoSec," a show about real people, their work, and its impact on the information security industry. Today, I'm joined by Tejpal Garhwal, the director of DevSecOps and application security at Pega. With more than 26 years of experience in application development and product security, Tejpal has led multiple security and dev teams, and set the direction for information security, application architecture, policy, and processes within numerous organizations. He holds numerous certifications and degrees from places like Harvard, The New York Institute of Technology, and The National Institute of Information Technology. Tejpal is a guest with so much expertise, and I cannot wait to dive into our conversation. Tejpal, thank you so much for joining me today.
Tejpal: Thank you, Caroline. Thank you for the opportunity to talk with me. I'm really glad to be here.
Caroline: Tejpal, let's start at the beginning of your career. What set you on the technology path, and what have been some of the most pivotal moments in your career?
Tejpal: Yeah, sure. So, you know, somehow I have been, like, really interested in breaking and fixing things, and that's my kind of interest from the beginning, from my childhood. And it's something, like, opening the radios or transistors, and looking it, and see how it works. And same goes with the TVs. At that time I had a CRT cathode rays TV, the big ones. I always try to open them up, see what is inside, and see how things work. So, that has always been my interest. And, you know, immediately after my graduation, I started developing software. And at that time, we had dBase III Plus or FoxPro. I don't know if people even remember that software, but those are the software I started building up. And I started selling those to local businesses. And because I, as in when I used to go to get the groceries for my mom, where always she used to send me to the store, and I see they have the booklet where they write with the pen, and give me the receipt. I say, "How about we make it with some automation?" Things like that. So, I build the software. I sell it to them. Sometime I just give it to them, and just show them that, "Hey, how cool it'll be, you can maintain and do it on the computer." So, that was kind of... I have always been interested in those. That's where kinda my interest started.
And another good moment in my career was I worked in one of the diamond processing companies back in India, my very early days. And I kinda helped build the software by, you know, maintaining the inventory and processing applications, how the diamonds get processed with the different stages, and how it can turn from rock to a diamond. So, that was kind of a really... I always remembered those moments. And also in Singapore and Malaysia, I worked on a project, it's called a scatter project, which is like provisory, control, and data acquisition, where your software interacts with the hardware. And I helped them build the software for the smart buildings. So, I was heavily involved with them. And in recent year, I mean 10, 15 years ago even, I built up the application where you have to write, you know, financial applications. I put entire logic in the store procedure because at that time the era was classic ASP, and not even .Net at that time. It was just transitioning into. And where could I hide or embed my logics, and I put that logic in the store procedure? And believe it or not, I'm not gonna name the company name, but they're a famous financial corporation, and they still have that logic or architecture where all the business logic is embedded in the store procedure.
So, that's where I'm coming from. And also, one more thing to point out, how I got into information security or application security, it changed really in one single day. As everything happens in the current market condition, in one fine day, we had a big layoff in the morning — say, "Okay, we are cutting costs, here is the pink slip." But the good thing happened the same day. At that time, I was working as the director of software engineering for product development. My CSO came to me and said, "Hey, do you want to join my team because we are looking for people who has a background in software development?" So, in one single day, from morning to evening, I'm transitioned from software engineering to application security.
Caroline: Wow. These are all such incredible stories. You know, I can imagine you as a boy going to the grocery store because your mom asked you to and, you know, offering to help with some automation and to show small business owners the power of computing. And then, yeah, diamonds and smart buildings and finance apps. And, you know, one of the things that I love most about this podcast is that our guests are all esteemed experts in the field. And yet, every single guest at one point did not know anything about information security. And in fact, there's a point in each of our lives when we had never even touched a keyboard. So, thank you so much for sharing that with us.
Tejpal: No problem. Yeah. Absolutely.
Caroline: Tejpal, your background brings together two fields that we talk a lot about in this podcast. One of them is software development, another is application security. And sometimes, we talk about these two as if they're two totally separate worlds that cannot mix together. What do you think about this?
Tejpal: You know, this is a very interesting question, Caroline. And also I would say that it depends on how we look at it strategically. But yes, to your point, these are still two different roles in some of the organizations in my observation. And it really comes down to how we build software, and what every organization's appetite is towards security risk. See, the developers always focus, in my observation, they're always focused on building cool features, developing great functionality to make their product better, and also definitely bring new features to the market, and stay ahead of the competition. And this all drives the business objective, and because of the competition in the market, and staying ahead of the game. So, there is no room, or there is no thought to even think about the security. And that's the developer's perspective. However, on the flip side, from security folk like me and some others, we all think about, talk about how to write safe code. How to keep our software that we are delivering free of vulnerabilities. How we can reduce, or have less risk or acceptable risk? And as a security individual, we are not always concerned about the functionality, but more concerned about the risk or the vulnerabilities. So, definitely, there's are two perspectives, and nothing is right or wrong, but we need to have something to glue together as in harmony where we can not only build cool software, but we also build this cool software as secure as possible.
Caroline: I like that perspective very much. And I wonder to what extent the SDLC can be the glue that you mentioned. Tejpal, I wonder, from your perspective, what makes a smooth and productive SDLC, and what kinds of things can help bring these two security and development mindsets and also practices together?
Tejpal: Yeah. That's another interesting question. And again, the SDLC is basically the, you know, the rail on which, the, means the company, builds software, this kinda framework or the stages. And these stages have not changed, or not going to change no matter what framework, or the development framework we adopt — agile or waterfall, whatnot. So, we'll continue to, you know, think about a new idea, we design it, we develop it, we test it, we deploy, right? These are, will remain the same at least in the near future.
Now, what we can do is to build the bridge between the development and security. How we can empower our developers with giving them the certain tool that can help them to, you know, surface certain security-specific risk early in the process? How we can build the software, which is secure by default, and secure as we are developing it? And all I'm coming down to say that how we can shift left, or think about security as early as possible in the SDLC. And here are some of the tools, or some of the strategy, but most importantly, is build the bridge, which can be done by security champions. Meaning, take representatives, or get the nomination of the representative from the development team. They can be an evangelist, they can be an ambassador, but they also have the appetite of at least to start understanding what are we talking about, and why we're talking about security. That glue and building the bridge is very important in the SDLC, in my view. And when we think about the SDLC, we know that each stage has certain, you know, quality gates, whether once you finish the design, then only we'll develop. What will happen if we can catch certain risks at the beginning of this phase, which is the design phase?
So, while we are saying, "Hey, one plus one equals two," the additional functionally that we are building, can we think about what could go wrong in that one? And that in turn presents secure by design, or can we think about the threat modeling for an example because you're designing it? And then, in the next stage, when you're developing it for an example, it would be cool to have some tools that can say when you are writing, let's say, SQL query and you say, "Hey, you are writing this query, and it can be prone to a SQL injection." Can we empower our developers with such tools that can help them to identify such a risk without making any additional effort? So, instead of thinking about security as an afterthought, which is if you look at the SDLC, and look at the right, that's where people or some of the organizations still think about security at that stage.
So, if we visualize, we can put certain security quality gates on the each stage of the SDLC, that way without doing any much effort, we can make it more secure. We can deliver more secure software. Just to wrap it up, so let's say, think about open-source scanning when you are developing the software, run the scans. And before you deploy your software, even before the testing, think about the dynamic application security testing. And then think about as soon as it's ready to go to the market, or out of the door, think about the penetration testing. So, as you can see, you have put certain quality gates in your SDLC where you will have better control or visibility, or transparency on the risk. And another thing, Caroline, I would like to mention is that if you're finding vulnerabilities at the end of the SDLC, it's expensive. Just, literally, there's a bigger dollar value on the vulnerability of the issues you find at the end of the cycle compared to early in the cycle. I hope that answers the question.
Caroline: What a beautiful and fantastic response. You know, a couple of items that I just wanna highlight. I love that you talk about it using these concepts of glue and of bridge building, and also incorporating a mindset of, you know, can we come together and think about what might go wrong? I love this, Tejpal. Thank you.
Tejpal: Okay.
Caroline: Tejpal, sometimes when people bring up this term DevSecOps, there's a way where sometimes what people mean is how can security people get devs to listen? When of course in reality as we've been discussing, it really should be a dialogue, it should be a two-way conversation. And if I am representing security people, I wonder if you can give me a developer perspective, and maybe some advice. What do you think makes it challenging to work with security people from a developer's point of view?
Tejpal: Yeah. I would say that in some cases, it's a big cultural change because as a developer, I would continue to develop my software the way I've been asked to develop, or that's how I'm used to. Which is again, to the earlier points, which we have talked about, like, focus on building cool features, focus on ready to go to the market, and stay ahead of the competition, right?
And I'm not really worrying as a developer about the security. However, as we talk about in the earlier question how we can build the bridge by having the security champions, and also, you know, think about, as simple as, what could go wrong? The software that I'm building, what could go wrong? For an example, as I mentioned, a threat model. It always looks as a very overwhelming plethora of new work that I have to do as a developer, and I don't have time. Because my clock is running, I have a deliverable timeline, and I have no room for threat modeling. That's one way of thinking as a developer. However, if I say, okay, threat modeling, I have 50 functions, if I look at the holistic view of the overall architecture of the function is that I'm developing, and as a developer, can I pick just one function out of, let's say, I'm making 50 functions. And think about that one function, what could go wrong? What could be the text surface I can see if I'm having, as simple as, a text box, can this text box be an issue for a cross-site script, for example? And if I can avoid that kindof vulnerability. So, as I'm saying, breaking a bigger problem as a small chunk and fixing that.
And if I look at the security perspective, and I'm just giving the example threat modeling, we can start small, pick one function, and scale it up. And you don't have to boil the ocean at one shot because security is a journey and definitely not a project. So, whatever we can do in order to start at least thinking and embedding in our thought process, in our culture that, "Hey, I have to do certain things in the design time. I have to do certain things in the development time." And it's just a start with the thought and that conversation, that's where the conversation starts. I do not know how to do the threat modeling, for an example, as a developer. That's where the dialogues start. That's where the conversations start. And that's where security champions come in the picture, and that's where the healthy conversation with the security people starts. Because now, we are building the partnership rather than two distinct sides of the river. So, I think if we start with that mindset, it's always easy to have a conversation. It always builds more and synergy. It always builds more, you know... the conversation becomes very healthy and productive, in my view.
Caroline: Fantastic. Tejpal, you have shared with us some of your perspective as a software developer, as an application security practitioner. I know that in your past you've also volunteered with organizations like Boy Scouts of America and the US Veterans Medical Center. I'd love to learn a little bit more about your efforts there, and why activities like these have been important to you.
Tejpal: Sure, absolutely. Thanks for asking this question because in our day-to-day life, we work for a job, whatever we do, but we always forget the aspect of connecting with the community. And that's where I think I love to stay involved in the community. And that's where I connected through Toastmaster International, which is the organization, non-profit organization for leadership and speaking skills. And I connected as a club coach because I had to complete certain credits for my distinguished Toastmaster award. And one of the clubs is the US Veteran Medical Center in Jamaica Plain, they were not performing very well. So, I was appointed there as a coach, which I picked and I had a choice, which club I should pick. So, I picked the US Veteran Medical Center, and helped that club to engage with people and, you know, tell them and teach them how public speaking can build their character, how professionally they can help them, and also cultivate leadership skill in them. So, that was my goal, and that was my objective to connecting with the US Medical Center through the Toastmaster International as a club coach. So, I was glad, and I always remember, I made friends over there. And I used to go there every Thursday to do the meeting, meet with the people, and always talk about how we can engage more people in public speaking, how we can build leadership skill in that organization.
And for the Boy Scouts, that's a very interesting phase of my life. My son is now graduated. He got the Eagle Scout, which I'm always proud of him, but I also find that is a good outlet. Boy Scouts is a very good outlet for parents to learn along with their kids. So, while my son was in the Boy Scouts earning his merit badge, but I was always helping him how to, you know, do the ski, or do the camping, and what challenges you can have during the camping, or how to set up the tent for an example. But at the same time, how to build leadership within the kids, right? How to talk, and how to interact, and how to bring the synergy with other kids. So, it's also another outlet, which really I'm always thankful to Boy Scouts because, indirectly, my son was in the Boy Scouts. Along the way, I was also learning a lot from the Boy Scouts.
Caroline: That's so wonderful. I love to hear about these other parts of your life as well. Tejpal, it has been so wonderful to learn about your story today. Thank you again on behalf of our listeners for your generosity in taking the time to speak with me, as well as for being so open about your experiences.
Tejpal: Thank you so much, Caroline. Thank you for your time. Appreciate it.
Caroline: "Humans of InfoSec" is brought to you by Cobalt, a Pentest as a Service company. You can find us on Twitter, @humansofinfosec.
.svg){kind=icon}
.svg){kind=icon}
