Implementing DevSecOps In Regulated Versus Unregulated Industries With Rohit Parchuri

[0:00:17.5] 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's developer security platform, helps developers build
secure applications without slowing down. Fixing vulnerabilities in code, open-source,
containers, and infrastructure as code. To learn more, visit snyk.io/tsd.

On today’s episode, Guy Podjarny, Founder of Snyk, talks to Rohit Parchuri, Chief Information
Security Officer at Yext. Rohit is an accomplished security leader with an established record
building, structuring and institutionalizing security principles and disciplines in the cloud hosting,
network hardware, cloud software and healthcare domains. We hope you enjoyed the
conversation and don't forget to leave us a review on iTunes if you enjoyed today's episode.

[INTERVIEW]

[00:01:55] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Today we have with us the VP and Chief Information Security Officer of Yext, Rohit Parchuri. Rohit, thanks for jumping onto the show.

[00:02:06] Rohit Parchuri: Of course, thanks for having me.

[00:02:08] Guy Podjarny: Rohit, there's a lot, you're the CISO there at Yext, but we talked about all sorts of interesting conversations that we can have over here. But today, we're going to dig primarily into this notion of DevSecOps frameworks and how you think about it, how do you think about it from a people's perspective, research, maybe we get a little bit into measurements. That sounds good, ready to go?

[00:02:29] Rohit Parchuri: It sounds perfect.

[00:02:31] Guy Podjarny: Before we dig in, can you please tell us a little bit about what is it that you do today, and maybe a bit about the journey into security into where you are today?

[00:02:40] Rohit Parchuri: Sure, I would love to. Currently, like you just talked about, I'm the VP and Chief Information Security Officer at Yext and this is my fifth month in the company, so a little new, still trying to figure out or get my bearings in. But before this, and you know primarily I'm responsible for building the cybersecurity program, and also GRC and privacy components, but then it's the journey has been fantastic so far. I'm looking forward to all the great things that the company is going to do, and also how my role fits into that.

Before this, I was with a company called Collective Health. So a little bit of healthcare experience and certainly was interesting, that was one challenge I wanted to take upon myself, and I'm super glad I did. Healthcare is completely a different domain and when it comes to cybersecurity, it's just all over the place. Well, I'm sure we'll get into more specifics and details around that. I was there for maybe a little over a couple of years and before that I was with ServiceNow for about eight years. I started in systems and network security, and then made my way into App and product security, a little bit of security operations.

I was basically responsible in building a few teams and disciplines within ServiceNow. Before
when I felt I was maybe being more jaded with the things that I've been doing and I wanted to
maybe take up a new challenge. That's when I shifted roles and took a CISO role of collective. You asked about the journey. For me, I think the cybersecurity concept itself dawned
unconsciously more so during my undergraduate degree. I was my degree in undergraduate as
an undergraduate was the Electronics and Communications. I was not in the computer field. I used to do an night college as well, which was more towards the software side of things when I
was satisfying my family, the other is satisfying myself.

So there was this project that we were working on in the electronics domain and given that was
the major, and we stumbled upon something called a rootkit. I'm sure everybody knows what a
rootkit now is, but back in the day, this I was talking about in 1995 days. Rootkit was pretty new
back then, and it was very fancy and shiny thing to work on. We stumbled upon it. I was really
thrilled about how it could actually tamper the programs and manipulate the computer
processes. I was pretty interested to look a little deeper into that. But my journey really began
not more so from a thread standpoint, but more so how do I actually think about defending from
something like this happening to the victims or people who are actually interacting with that
unconsciously, for the most part.

So that's really how it began. Then I applied for a few universities to see if cybersecurity is even
a thing, or some people just talk about it. Well, I soon figured it was actually a thing and there
were a few universities or given out the degrees, from then on, I took up that.

[00:05:35] Guy Podjarny: Got it. Very cool. Well, thanks for the reverse journey a little bit there. You just
need to get the bug at some point and then. We're going to dig a bit more maybe the specifics of
it, but you've gone from a tech platform to a health platform, I guess, also tech, but from a
different level of maybe regulations and such into Yext which probably resembles ServiceNow,
more in terms of its regulatory perspective. How is it a stark difference? I mean, how significant
is it to change those worlds?

[00:06:11] Rohit Parchuri: That's a great question. I think it is. I wouldn't have responded the way I'm doing
right now, if you asked me a couple years ago, because I wasn't expecting that to be the case. I
felt cybersecurity is more comments and stuff. Again, people would actually embrace the
concept and start working on that. But that's not really the case. I'm sure the listeners here
coming from the security background, you can relate to that. It's always a journey, there's a
certain friction, you have to navigate the space etc. But for me, the stark difference, really, I was
able to see is between the product delivery versus the healthcare delivery.

So ServiceNow and Yext product facing more on the product side of the house, whereas
Collective Health is completely on the healthcare. It also has to do with more the way I would
think about the security programs within any healthcare space, it's more inside out than outside
in. What I really mean by that is, you're not really delivering a lot of features or what I mean is
security features or security enhancements, per se. But you're managing your partners and
vendor ecosystem a little more than you would typically do on the vendor or sorry, the product
side of the house.

The reason for that is healthcare has a number of antiquated processes and vendors we have
to work with, and a lot of that work has to do with paper, physical paper. You would think in this
day and age, you still have to deal with paper, which is absolutely true, you still have to deal with
it. The problem is there's a lot of PHI, Protected Health Information happens to be one of the
most sensitive and confidential pieces of information that you can find in this country right now.
With that in mind, we're not only talking about the paper, but also how do you transform that,
convert that into EPHI, Electronic form of PHI, and then you have to have a program built
around that.

So you're capturing the physical aspect and the digital aspect of things, which is where it gets a
little complicated I felt, and more importantly, you're talking or you're partnering with, when I
talked about antiquated I'm not just talking about the processes themselves, but also talking
about the mindset of the people. When we partner with these folks, they hardly know what the
difference between a security verses or something else is. A lot of people are still catching up to
the digital world. A lot of people are still going through the migrations from physical to digital. It's
really difficult for us to even have a straight conversation about security, let alone talk about the
programs and maturity frameworks, things like that. That's never going to happen. That's a non-
starter.

For me, that's a stressful place to be at. At the same time, I can say I learned a lot of things
really about how do you build the culture, not just for the people who understand the concepts,
but with the people who don't understand the concepts where you actually want to empower
them with the right things. This is not in terms of tools, right? You are actually trying to build the
mindset. The most difficult terrain you can find is a human mind landscape. That was one of the biggest things where I found about how a technology farm operates versus a healthcare farm,
for example.

[00:09:17] Guy Podjarny: No, I think there's a there's definitely a lot there. For context, Collective Health
itself is a more technology-driven company in the healthcare industry. And a lot of those
challenges, did you encounter them within Collective Health and the reality they're in, or is it
more about Collective Health as partners and customers in the ecosystem that was the
challenge?

[00:09:37] Rohit Parchuri: Yeah. That's a great point you brought up. So Collective Health is a cloud-first,
microservices, architecture, everything you can think about. How we operate our infrastructure
applications at scale in this day and age, that's what Collective Health is and they're pretty
focused and pretty - they have a great vision in how they want to build the products that are
upgraded, used and benefit for people. The problems are the friction that I've seen, it's not with
the leaders not with the company itself, the culture has been pretty strong, right? When you're in
healthcare, HIPAA is its table stakes, right? HIPAA by something you have to do and more. It's
actually much easier for us to talk about GRC in a healthcare or a heavily regulated space than
in the product space, for example.

The problem is more so, how do I take that? How do I take the HIPAA journey, for example, with
my vendors and partners? That's the difficult part, which is when the external-facing interactions
happen.

[00:10:34] Guy Podjarny: Yeah, yeah. No, that makes a lot of sense. I guess, indeed, let's talk
DevSecOps. Talk a little bit about how do you implement it? I think one of the great perspectives
you have here is indeed the healthcare surrounding maybe, and the Yext running, but in both
those cases, your own company Yext and Collective Health are agile DevOps, fast-moving
companies. How do you think when you talk about weaving security into development or into the
activities? What are some of the core principles or approaches that you use in such a fast-
moving space? How do you tackle it?

[00:11:15] Rohit Parchuri: Yeah. It's a difficult question to answer. I will definitely start with that disclaimer.
There is no one size fits all, every fast-paced organization, every leading-edge organization, for example. You have to start or leave with the why. Like why are we even doing this in the first
place? Then assess the other attributes on how you want to build the program. But I'll talk about
what worked for me, and maybe we can expand it from there. There are a few key ingredients
that I focus on when I'm taking up the hill, like when I come into a company, when I'm trying to
assess what cybersecurity program do I need to build both from a culture standpoint, and also
from a staffing standpoint?

The ingredients I want to talk about is a culture. First and foremost, like how do you build a
culture or a security mindset across the company? Are you starting from ground zero or did
somebody else do the work for you and are you starting at level one, level two? Whatever that
may be. But the culture is so important, I can't stress enough the importance of that, and a lot of
people don't take that. I definitely am not an exception to that. I've learned this the hard way
myself, in order for you to have a successful program, a successful interaction, and influence
people to take the right decisions from a cybersecurity standpoint, because that's what you're
responsible for in a company, you need everybody rowing in the same direction. And culture
plays a critical role in that.

However, there is a combination of things still. You can just focus on the culture, there's also
automation enforcement. When you establish the culture as the foundational principle then you
take that level up and say that, "Okay, this is what - how we want to define the practice within a
company. And these are the tools or the frameworks that we would enable for us to get things
done at scale, and also optimize as we go along." I would start there, and maybe depending on
how we work as a company, or what direction are we taking from a product or a sales strategy?
I would pivot then course correct, as needed.

[00:13:19] Guy Podjarny: Are there specific frameworks that you start from? I mean, when you're, you've
worn a similar hat in three companies now. Are some go-to?

[00:13:27] Rohit Parchuri: Oh, absolutely, absolutely. I wouldn't lie by saying that I start something of my
own, right, because there are a lot of great frameworks and a lot of industry experts who
actually worked on it. So why reinvent the wheel when you already have a trove of information
available. But the way - it's not so much about the framework, but the way I approach it is what I feel comfortable with the things that I do, and I'll talk about the frameworks in a minute. But I
would delineate this to into program-level frameworks and control frameworks.

A program-level framework for a CISO is so important, and even for folks in the internal audit, is
"What direction are we taking as the company when it comes to cybersecurity staffing, spend,
the program objectives, etc?" So that's really setting the narrative or the dialogue to begin with.
This is what I would use to talk to my board, talk to my executive team, figure out what direction
we need to take in terms of compliance certifications, regulatory, etc. The extension to that is
what the control framework itself is. So the control frameworks are how do you manifest the
program framework into practice? Simple things like how do you build the security principles,
the architecture, the principle of lease privilege, architectural considerations, threat modeling,
scanning the whole gamut, right?

A few examples for me in terms of program framework, NIST CSF has been super helpful. I'm
sure most of your listeners or folks in cybersecurity attest to that. It's very comprehensive. It's
very holistic, but also you have to make a judgment call in terms of how much does it align with
your company objectives. All it comes down to when you're trying to select a certain you don't
have to be married with a certain framework, but what all it comes down to is, like how do you
align that with your company objectives with your company goals? Because having a framework
by itself is not really going to help anyone, including yourself.

How do you align with that, and then show you the direction that you want to take both from a
cyber-standpoint, also from a company standpoint, is super helpful. Controls framework, what
I've used in the past is the CIS controls. They - I think they used to have Top 20, but now they
actually came up with the CIS controls. I've used that in the past. I feel comfortable
recommending that myself, because there are a few things you want to start off working. They
give a step by step guidance on how you want to achieve that.

The last one, I would say is the behavioral framework when it comes to DevSecOps specifically.
A couple, one is the BCM. This was developed by Synopsys, I believe. Then the other is the
Open SAMM, and I'm sure many of you know about Open SAMM, this has been developed by
OWASP. I think it had multiple iterations. So those are a few things I would start with.

[00:16:10] Guy Podjarny: Yeah, no. That's a great outline there for, you have your program and the
framework for that, the framework for the controls and the ones for the behavior. You said, that
it's specifically BCM and Open SAMM are especially useful for DevSecOps. I mean, what makes
them I guess, what's different about what you would look for in a framework, when you think
about DevSecOps surrounding versus not?

[00:16:35] Rohit Parchuri: Yeah, I think, maybe let me take a step back and help you understand about
how I would approach the whole DevSecOps model or the maturity in general. It all depends on
what product software development life cycles that you have as a company, and how you're
building your products, how you're deploying your products, the post-deployment monitoring,
things like that, right? You have an engineering team, you have technology operations, and they
do follow certain disciplines and functions.

So it's not - they should not align with how you're building out, but rather it should be the
opposite, so you have to align with theirs and this is such a great example of what Snyk does and
what you guys do is exactly going there, right? Because you're trying to integrate with the
workflows and processes that the dev teams have, and for me that's been a holy grail. That's
really how I got a lot of things down, like really influencing people on the why, and then trying to
pivot my direction towards how the PDLC and SDLC operations really happen.

[00:17:41] Guy Podjarny: Yeah, yeah, it makes a lot of sense. Really it's all about empathy and the job
and, I guess, adapting to where you want security to be applied for instance, within
development. Is there a difference - I guess you've worked mostly in these types of fast-paced
surroundings, but are there any notable failures, if you will, like things that you tried to apply that
doesn't seem to be working in this fast surrounding?

[00:18:06] Rohit Parchuri: Oh, man, a lot of failures, a lot of failures. I mean, I would say 75% failures and
maybe 25% successes. Maybe I'll talk about a few examples. One is this whole practice about
getting closer to the developers or developer ecosystems only happened because I failed the other way. I failed because I was creating my own dashboards. I was asking folks to work on the
security tools that I built out the processes that I am managing, right? So when you have so
many isolations and when you're working in a vacuum, it gets really difficult not for the people
not just within your team, but also people who are interacting with you on a day-to-day basis.

Our customers, of course, happened to be developers and at least when you talk about the
DevSecOps, and you should be catering to them, and really understanding the pain points and
the challenges that they have gone through. I did not do that. I can see this loud and clear, I've
failed on that. This definitely goes back to my Service Now days, when I was trying to establish
this practice, when I was trying to create the DevSecOps, which is pretty new still.

I think anything that I'm trying to take them out of their workable processes or something that
they're used to doing, and place them in a different channel, you would feel it's going to work for
some time, but it's not a long term accomplishment. You're never going to keep up with that.
There's always going to be something coming up and there's more friction than actual work
that's being done. That I would say is definitely the biggest one I know I experienced myself.

[00:19:36] Guy Podjarny: Yeah, well, I think that's a great, great lesson. I think I dove a bit deeper into this
rabbit hole. Maybe if we, if we bump up back a little bit and we talk about the different
surroundings there, of Yext versus Collective Health, the more regulated versus less. Now you
have these different frameworks, you have the desire to adapt to developers. Is that different in
the highly regulatory - does the same approach work?

[00:20:07] Rohit Parchuri: It's a good question. I'm trying to think. I'm sure it's different. So, you know how I
spoke about how highly regulated industries start off with a premise that you have to comply
with certain regulatory obligations. It's not so much more contractual obligations, I’ll talk about
that in a minute, but more so what do you need to satisfy to the government or in the legal
space before you can start operating as a business? With that in mind, I think as soon as you’re
as a part of your new hire orientation, it's injected into the employee's minds that this is the bare
minimum that we need to have. This is the table stakes, right? So work towards that.

So you're not starting at ground zero when it comes to GRC aspect of it. I'm not going to say the
same thing applies for all the other cyber practices. DevSecOps is a very specialty skill, and a
very specialty domain that not a lot of people understand exactly the benefits or sometimes not
even know how to operate that. At the highest level, people would know developers or any
employee at a company would know, that this is what we need to achieve, this is a check box,
right? Just like you would do a performance check box, you need to do a security check box, so that your HIPAA compliant or PCI DSS compliant or FedRAMP, compliant, whatever that, but
that's not really going to take you to a place where you're secure in your own true nature.

That's one thing I've found, there's a difference in how you approach the discussion, approach
the dialogue with the folks when you're in a heavily regulated space versus not. In the product,
though, everything happens, the discussions that you would have, you need to lead with the
why, right? What's the benefit for me to do this? Everybody wants to do the right thing, that's this

• it's not that they hate security. I get this a lot. People feel that security is a policing agent,
  they're coming in, and they're throwing a bunch of things in our heads and they leave.

A lot of effective security leaders don't do that, they're actually the opposite. We enable the
teams to do the right work at the right times. At the same time, we want to defend ourselves
from certain things, bad actors, regulators, etc. So in the product side of the house, at Yext that
Service Now, we talk about the benefits to begin with and then we showcase what models have
been driven to support the case? This could be an enterprise security assessment at the highest
level, or bring it down a notch and talk about threat modeling, use cases that we come came
about, and then we drive the discussion downwards.

So in both cases, though, one thing is common, you need to have the executive or board weigh
in on the decisions that you're taking as a company when it comes to cyber. If that doesn't
happen, the bottom-top approach is never going to work. The top-bottom is something you want
to start with and then include the operations and practice at the line manager levels or adding
chair levels, for example.

[00:23:02] Guy Podjarny: Yeah, got it. Let me echo this back. You're saying in a regular surrounding,
achieving the needs for compliance is easier than maybe in an unregulated one, because
people are like, it's hardcoded into people that you have to do X Y, Z, and they understand I
mean, health care, I'm going to worry about it. But it almost makes it by virtue, you need to -
they need to unlearn that a little bit when they talk about slightly less compliance-oriented, just
pure security, mindfulness, or awareness, to security concerns. But either way, whether it's
regulated or unregulated, you lead with the why, and just the why is not compliance, or
sometimes its compliance but the why can be, it can be a fair bit more. Did I get that correctly?

[00:23:45] RP: That's accurate. Also, I'll touch on this, like why it's a combination of your
obligations as a company that you have to meet for your customers and government at the
same time, but also your due diligence, right? What do you as a leader, what do you as a
security person want to defend your organization from? Because that technically is how it
should start, but unfortunately, we can't have that dialogue without satisfying the first part,
because the company leadership is looking for, how is this going to enhance my bottom line?

How is this going to push my expenditure revenue for the company? How would you think about
this? Like you have to start with a business mindset and then you go into technical mindset. But
for me, being a technologist myself, I definitely touched on, more on the thread aspect of things,
which I shouldn't, which again, is another lesson that I've learned recently. That's yeah, those
are a few things I would also touch on.

[00:24:40] Guy Podjarny: Yeah, yeah, for sure. We'll get back - I'm actually tempted to go to measurement
here, but I don't like, let's put a pin in that and come back to it after. So instead, let's talk people.
So we talked a little bit about the developer engagement, but the security team itself, when you
talk about building a team staffing up for it, what do you look for in a hire? And maybe what are
the warning signs? What are you moving to avoid maybe if you're talking about this being
different and difficult being a specialized mindset?

[00:25:11] Rohit Parchuri: Yeah, yeah, even, that's a great question, by the way. And I think security's
discussion or anything that has to do with cybersecurity right now, it's in each element in the
market. A lot of people tend to look at this in different ways. My way of thinking about this, you
start with the baseline, for me respective of the specialty, you start with a few things. Like for
me, you have to have a threat analysis skillset, combined with programming and systems
knowledge, not experience, per se, but understanding concepts, the basic programming
concepts, the basic system concepts.

Given we're in the cloud-first and microservices architectures, right now, you see this more and
more now, because you're not only dealing with a single layer defense, you're not talking about
application by itself, even though you have an application security engineering, they have to do
much more than looking at the application threats. They have to go into Docker for example, what orchestration services are we running? How is this all combined? How is this actually pulling it into a threat vector? Or what threat landscape are you looking for?

I would say security folks need to have a holistic security coverage, no different than a full stack
developer would. In the past, we never had a concept of full-stack, but now we do, because
there's a reason for us to do it. Otherwise, we wouldn't actually build the apps that we're
developing right now. That's the first thing that's the baseline, I would start off with.

[00:26:34] GP: It’s a cool concept. I don't know that I've heard of a full-stack security person. It's interesting, because they do indeed, hear about the - and I can relate to the dual need of
understanding security on one side, but then have some programming mindset or understanding the platform. How deep do you require going into that programming side? Do you expect people to hire to know how to code? Do you expect them to show some TerraForm proficiency or Kubernetes proficiency? How do you think about weights, if you will, right, in terms of what's more important? Can you teach security more easily than programming or infrastructure? Or vice versa?

[00:27:16] Rohit Parchuri: Yeah, and also it shouldn't be or it's not supposed to be like, it's a single kind of
discipline we're looking for, right. There are different specialties within security. Security is a pretty broad topic. We need different people. We need a really good coverage across the realm
in terms of how we view these people. They're really strong, non-technical people. There's a
really good benefit that we would get out of them, and then there is a really strong technical
people, but there is a middle ground too.

The way I would think about this is, I think, this is, I'm not going to credit myself on this one. Phil
Venables from Google, I think he's a Google Cloud CISO right now, he actually spoke about a
model where you combine a few elements of skills within a security group. He talks about risk
advisors, subject matter experts, and operational analysts. What that means is, when you're
trying to build a well-rounded security team, you need to have a good combination or a healthy
combination of people coming from different disciplines. Think about an application security
engineer, what's the easiest way for me to actually have a person come in, hit the ground
running, and actually get to the things that I need him or her to do?

Coming from a software background is super helpful, because it's easier for me to teach them
security. Security, in my opinion and not a lot of people agree with this, but it's more common
sense than the actual skill. When I say common sense, I'm not talking just about the technical
part of it, but also the people skills, the influential skills. Like when you come in, I talk about this
and other their discussions too. When you're thinking about security, you're talking more in
terms of not enforcing something, but how do you bring the people along the journey, in terms of
getting things done.

So you're reporting the risk, you're not really executing on it. Somebody else is executing. So
you got to influence people to do the right thing and of course, you got to show the benefits and
whatnot. But the way I would position that is, if you're coming from a developer background, it's
so much easier for me to teach that element, as opposed to if it's turned down, like if you're
solely on the risk or maybe on thread stat style side of things. For example, you're a security
engineer, you've been working on this for a little while, but your focus on programming is so
limited, but your role dictates that you need that in order for you to move forward or you don't
take the function within the company forward. I would position the background from software is
better.

The same thing would apply to network security engineers or cloud security engineers, for that
matter. You spoke about Terraform right? What’s Terraform? Just a different form of programming. You have the concept you have the fundamentals built in. In the past, we used to
use, we used to, I used to have a template just for object-oriented programming. I used to have
just a few things that I would ask them and do see how, what expertise do they have in that?
Then I would take on the next threat modeling or whatever the security terminology is there,
right. I would say having a strong skill set and one of the functions that are outside of security,
and then coming into that, it's much more easier for me to actually keep the data for those
people.

[00:30:20] Guy Podjarny: Yeah, yeah, that makes sense. That's consistent with what you've been
describing around the tooling, so you have to relate to that tooling and around the centricity. The
idea of, you have to align yourself to the model of, know how the team that you're looking to
help secure their work is actually operating. So having the core over there is probably better
then coming with the, "I know what to do, just listen to me," starting point.

[00:30:47] Rohit Parchuri: That's the worst. Oh, my God. In security, I think you've got to be people smart,
right? Otherwise, you wouldn't go far, especially in security. It's true for other fields too. But just
given you're trying to make other people work, you got to know how to pull the strings, you got
to know how to talk about the right things at the right time. Otherwise, it's just, it's going to be a
broken concept, it wouldn't really manifest itself into a true benefit, for example.

[00:31:13] Guy Podjarny: Yeah. What's, if we're maybe thinking a little bit about tips and tricks, what's a
favorite interview question that you have to try and people's disposition?

[00:31:22] Rohit Parchuri: Oh, I'm glad you asked. I think I do have one. Maybe I'm spilling the beans now,
because everybody listening to this would have the answer ready. One thing I would ask for is to
threat model. I wouldn't have a certain scenario in mind. I would build up a scenario when I'm
talking to this person, whatever the expertise is. I would risk request for specifics when you're
performing Threat Modeling, and how that applies to their specific role. So I would start off with
the non-technical aspect of threat modeling, and then go into technical aspects. This is for me to
assess the path process on how people think about security. The reason for that is, it's a certain
skill in terms of how you put the thought into practice, when you come to security, right?

Everybody can think about security, right? How do you carry that torch to a place where you're
not only identifying the issues, but also making sure you do have the right defenses in place.
This is where thinking out of box comes into play, because academically your thought about
your top two, if there's a cross site scripting, okay, what's the fix? Whitelisting or escaping?
That's not the reality, right? Reality comes in multiple forms and sometimes you don't even have
an answer. So how do you adapt, and course-correct, depending on what situation you're faced
in. So that's what really blends between the non-technical, technical aspect of threat modeling.
That is something I've had much success in the past and differentiating between a successful
candidate versus an unsuccessful candidate.

[00:32:53] Guy Podjarny: It's great. I don't think you're hiding anything, because I think the beauty of such
a question is that it's broad enough that it shows you that people are doing it. When I was a
CTO at Akamai, that was the webspace in one of my favorite questions was, you open a browser or you put a URL and you hit enter, and a webpage shows up? What happened in the process? Then people will take it down, some people would break down more the rendering of the webpage, some will do more network minded. Some would describe more high-level, some
would go low level. In oftentimes is actually these types of open questions are useful to just
show where people bias, right? –

[00:33:31] Rohit Parchuri: I like that. That's, yeah, that’s a really nice question to ask for sure.

[00:33:35] GP: So we're starting to run out of time, a little bit here. I do want to talk a little bit
about the methodologies and the frameworks. We talked about people and some of the hiring.
Let's talk KPIs and measurement. A lot of different activities here choices, frameworks, hiring,
how do if you're doing it correctly? What do you use to measure the success of yourself, of your
team, of the program?

[00:34:02] Rohit Parchuri: Yeah, oh God, you just open a can of worms now. The KPIs and it's a never-
ending dialogue when you come to security, right? Because you're always faced with the
questions about what's the return on investment when I'm trying to sign this off for you. I'm just
going to say this, right, there's no one size fits all. We have to tailor the metrics, the telemetry,
whatever the KPIs or key risk indicators now, what they're some of the leaders call it. It really
depends on how you're trying to build the program out and how do you see yourself accomplishing that?

A few things, ultimately, it boils down to, what do your customers need from you? What does the
government need from you? What do you yourself need from the program? So I would focus on
those three elements to begin with and let that be a guiding pathway to build out your respective
KPIs. A few things that work for me, I'm just going to talk about my experience governance
metrics. When you have GRC programs you got to focus on at the highest levels. How are you
trying to define a program? How do you show the success or the pathways that you're taking in
order to be successful?

Basic expected controls conformance, for example, patching Identity and Access, configuration
assurance, any deviations that you capture, this could be quantifiable, this could be quality-
related, it really depends on how you're building the program out or how specific you want to get
the information out. There's also the audience, right? Are you conveying this information to the board executive team, then it of course has to cater to that audience, which means it has to be
at the highest levels, and you don't go into specifics. But if you have an ISOC for example, in a
charter committee, or something where you have a group of people taking decisions in terms of
what security means to the company, you have a different way of approaching that.

Then there's also service and acid risk-oriented metrics. The way I would think about this is how
the measurement of risk to specific groups of assets or business services in relation to maybe
attacker motivation or attacker capabilities. The examples or some of the factors you could use
here would be the layers of complimentary defense from an attacker to a target, degree of
pressure on controls, for example, like are you making it difficult for an attacker even after they
compromise the first layer of defense to come in get the final target, the dwell time.

Things like these also, what you could also do is have simulation exercises, and you don't, not
every team would actually have the realistic metrics, you can always do simulations and figure
out what, how these metrics evolve and how they manifest themselves. The last thing I'll talk
about, which typically is most important for many of the companies is the commercial outcomes,
and also the competitive advantage that you have when you compare yourself with others in the
same market space. So what direct or adjacent benefits are expected in addition to loss
avoidance for example, risk reductions, security outcomes, right?

A few factors that you can think about is, maybe the customer sign upgrades, you do seamless
authentication processes that have as a product feature or maybe increase collaboration and
support off customers or reduction of employee overhead or maybe time spending, managing
control still, because every time you build a control, there's an operational lifecycle to that. So if
you're trying to reduce that, and still be able to optimize it, that's a great metric to talk about.

[00:37:29] Guy Podjarny: Yeah. For this last one, is it around measuring the avoidance of something? So
when we think about the authentication, do you mean here you assume some maybe baseline
of what's bad or maybe what's the normal? You're trying to measure how, how far away are you
from it? Just trying to understand.

[00:37:49] Rohit Parchuri: Yeah, so it's twofold, right? One is, what are the table stakes for you, when
you're trying to define the security controls for your customer space? What is the difference between yourself and your competitor? Are you making it easier for people to bootstrap security
principles or controls as a part of your product? Or are you making it difficult for them to actually
go through that journey?

In some cases, it has to be security faults, right? No questions, as you're going to get this by
default, you don't have to lift a finger. But in some cases, it's much more complicated than that,
you have to have a customer action before you could actually manifest the benefit of security
control. That's what I would think that's one part and the other part is also how do you manage
your own workforce from a security standpoint on managing or pushing these patches or
security features out? Are you trying to reduce the unit cost of a control?

If you're doing that successfully, that means you're actually going in the right direction, because
the - when you start off with the control, right, it's going to take a while before it can start
providing benefits, or you can reap the benefits off of it. But over time, if you have, if you're
doing the right things, it would be more of an automated enforcement. Like things you're
building out, the investment that you put in, the expense that you put in is actually going to come
down. So those are a few things. I would say that that speaks volumes to how you're building
the program.

[00:39:13] Guy Podjarny: Yeah, okay. Yeah, I think it's interesting. You're right, that it's a can of worms
here, could have probably gone deep on each one of these elements. I think it's a great
overview of the different types of KPIs, that you would have. Clearly oftentimes the challenge is
consolidating them. Maybe, squeeze one final question on this before we ask you my typical
closing question here. So you in passing there, said there's KPI when you said well, but there's
also key risk indicators. When you're in a security leadership role, do you see the two as the
same? Is KRI, I guess I haven't actually seen that in acronym form, but as a KRI the same as a
KPI?

[00:39:55] Rohit Parchuri: I wouldn't say that. Some people do inflate them together, but for me, I treat
them separate. Performance, in my opinion is trying to build elements within the program and
trying to look at what that accomplishment looks like and then derive the metrics off of it. A good
example would be, let's say we're trying to build a single sign-on. That's a performance metrics,
clearly, because you're building a project. Yes, there's a risk you're trying to address, but more importantly for me the direction is more important than what we're trying to address when you
talk about the KPI.

The KRI on the other hand, and you're right, it is called KRI's, the risk on how you talk - or
maybe even the best way to position that is, let's say you have a top 10, or top five risks that
you're trying to present your work. Those happen to be the highest level of theorize. Each KRI, I
can have multiple KPIs, but not the other way around. Risk is something you're trying to
address. What KPIs are you trying to perform or trying to retrieve? So you're actually trying to
address that key risk indicator, for example.

[00:40:58] Guy Podjarny: Yeah, yeah, that makes sense. The performance is really around the execution
towards reduction of risk.

[00:41:03] Rohit Parchuri: Yes. Good way to put it.

[00:41:05] GP: Rohit, this is, it's like a broad, and we have so many topics to do it. But we run
out of time. So before I let you go here, one final question that I to ask all guests coming on the
show. If you imagine someone sitting in your seat five years from now, not necessarily in your
company and more on your type of role, what would be most different about their reality? What
would be higher? Lower, harder, easier, most different?

[00:41:34] Rohit Parchuri: Oh, man, it's a tough one. There's so many things I can talk about. I'll just
maybe talk about a few things. I think inflation, I think we spoke about this a little while ago, the
security stopping. Right now, there's a lot of demand for security folks. Supply not so much,
right? Which is why, it's getting really difficult for us to find quality security engineers and when I
say quality, I talked about all the attributes that go into quality engineers, so that's exactly what
I'm talking about. Finding quality engineers is a difficult task. I think the inflation of these
specialties, in general for cybersecurity is only going to grow, both from a role diversity
standpoint.

Also, you see this now the proliferation of solutions that are out in the market for cybersecurity,
are growing in size. I think that's going to keep growing, I'm not sure what the upper limit is going to be. I think the person sitting in this position five years from now has to navigate through all this noise, weed out the, what exactly they need to have, in order to build the program, mature the program out, maintain the program, whatever that may be, rather than dealing with
the shiny or the beautiful thing out there.

I'm not saying everybody does that, but it's easy for us to look at what's new. We already have a
solution in place, but there's a new one that's cutting edge and something we want to implement. So it's easy for us to take that and refactor that, but not a lot of people think about the total cost of operations. When you do that, migration costs, deployment costs, it just adds up. On one hand, and no offense to the vendors out there, but you have lenders pushing you towards the solutions that are out there, and yeah, this solution is better than this one, please consider this, you do a POC, you do a POE and then end up doing that, but you fail to see what's really the long term.

That's one thing I feel is something that's only going to grow in size, and you have to have critical thought process put into before you start establishing something. I for one, don't shelfware. If I'm using something, I'll make sure we squeeze every penny out of it before I go to the next one, but that's just me, but I feel that that space is definitely going to go more complicated and inflated.

[00:43:52] Guy Podjarny: Yeah, yeah. Sounds like basically the fragmentation that aligns with I guess what we've seen with DevOps and to an extent with decentralization. That all these motions are causing, you have a lot of teams will pick different tools, they will need different tools for it.
That's a reality that we've, I can't say that the DevOps world is thrilled with it, but has made peace with it, maybe learns to accept it a bit more. So like a security with a would, would be facing that as well. Rohit, this has been great. Thanks a lot for coming onto the show.

[00:44:26] Rohit Parchuri: Of course. Yeah, it's been really fun. Thanks for all the beautiful questions.
[00:44:30] Guy Podjarny: Thanks everybody for tuning in. I hope you join us for the next one.
[00:44:34] Rohit Parchuri: Thank you guys.

[OUTRO]

[00:44:39] 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]