Artwork for podcast The Cybersecurity Readiness Podcast Series
Reducing the Disconnect Between Security and Development Teams
Episode 2625th May 2022 • The Cybersecurity Readiness Podcast Series • Dr. Dave Chatterjee
00:00:00 00:31:47

Share Episode

Shownotes

How do you make security a first-class citizen of the software development process? According to an industry report, “many information security engineers don’t understand software development—and most software developers don’t understand security. Developers and their managers are focused on delivering features and meeting time-to-market expectations, rather than on making sure that software is secure.” Harshil Parikh, CEO and Co-Founder Tromzo, shares best practices for reducing the disconnect between software development and information security engineers. One such practice is the establishing and automation of security guardrails for application development.

Time Stamps

00:41 -- Talk a little bit about your background, and then we can proceed with the discussion.

02:15 -- According to an industry report, "many information security engineers don't understand software development, and most software developers don't understand security. Developers and their managers are focused on delivering features, and meeting time-to-market expectations, rather than on making sure that the software is secure." What are your thoughts and reactions?

04:10 -- Security personnel are incentivized to ensure the product is highly secure. Developers are incentivized to make sure the product has all the functionalities and gets to market on time. So, the incentive systems are often not aligned. That's one of the reasons why there exists a disconnect. What do you feel?

06:36 -- What practices, what structures, are in place to achieve the dual goal of quality software that is also very secure?

08:18 -- Why is it that these teams (software development and information security teams) must be separate? Why can't they be fused and work as one team towards the delivery of a particular product?

12:49 -- Share with the listeners some best practices for reducing the disconnect. What would be certain things that folks could do in their organization within their sphere and scope of influence?

17:14 -- What are some best practices for building and scaling a modern application security program?

24:55 -- How do you empower AppSec teams so they can focus their time on more high-level strategic work?

27:43 -- I'd like to give you the opportunity to put it all together and wrap it up for us. So, what are your final thoughts?

Memorable Harshal Parikh Quotes

"The unfortunate reality of our current world is that most engineering leadership does not measure developers or does not incentivize developers on building high-quality code that is also secure, to a reasonable extent."

" I doubt if most companies are in the business of building the most secure software ever. That's just not the reality of the world. So, how do you find that balance of being agile, being fast, but also being able to incorporate security to a reasonable extent that works for the business."

"Our world is nowhere close to being automated by bots because it is complex."

"If development is continuous, deployment is continuous, then security should also be continuous."


Connect with Host Dr. Dave Chatterjee and Subscribe to the Podcast

Please subscribe to the podcast so you don't miss any new episodes! And please leave the show a rating if you like what you hear. New episodes release every two weeks.

Connect with Dr. Chatterjee on these platforms:

LinkedIn: https://www.linkedin.com/in/dchatte/

Website: https://dchatte.com/

Cybersecurity Readiness Book: https://www.amazon.com/Cybersecurity-Readiness-Holistic-High-Performance-Approach/dp/1071837338

Transcripts

Introducer:

Welcome to the Cybersecurity Readiness Podcast

Introducer:

Series with Dr. Dave Chatterjee. Dr. Chatterjee is the author of

Introducer:

Cybersecurity Readiness, A Holistic and High-Performance

Introducer:

Approach. He has been studying cybersecurity for over a decade,

Introducer:

authored and edited scholarly papers, delivered talks,

Introducer:

conducted webinars, consulted with companies, and served on a

Introducer:

cybersecurity SWAT team with Chief Information Security

Introducer:

officers. Dr. Chatterjee is an Associate Professor of

Introducer:

Management Information Systems at the Terry College of

Introducer:

Business, the University of Georgia and Visiting Professor

Introducer:

at Duke University's Pratt School of Engineering.

Dr. Dave Chatterjee:

Hello, everyone. I'm delighted to

Dr. Dave Chatterjee:

welcome you to this episode of the Cybersecurity Readiness

Dr. Dave Chatterjee:

Podcast Series. Today, I have the pleasure of talking with

Dr. Dave Chatterjee:

Harshil Parikh, CEO and Co-Founder of Tromzo. Tromzo

Dr. Dave Chatterjee:

empowers developers and security teams to collaboratively and

Dr. Dave Chatterjee:

effortlessly build secure software. Harshil welcome. As we

Dr. Dave Chatterjee:

discussed during our planning meeting, our theme for our

Dr. Dave Chatterjee:

discussion today will revolve around reducing the disconnect

Dr. Dave Chatterjee:

between security and development teams, obviously, you're an

Dr. Dave Chatterjee:

expert in the area. And I'll let you introduce yourself. Talk a

Dr. Dave Chatterjee:

little bit about your background, and then we can

Dr. Dave Chatterjee:

proceed with the discussion.

Harshil Parikh:

Fantastic. Thank you, Dave, it is my absolute

Harshil Parikh:

pleasure to be a guest on this podcast. Just to give a little

Harshil Parikh:

bit of background to the audience especially, I've spent

Harshil Parikh:

quite a bit of time in the space of cybersecurity, done a lot of

Harshil Parikh:

things, started my career as a network security engineer back

Harshil Parikh:

in the day when firewalls were a big thing. And then eventually,

Harshil Parikh:

most recently, I was the head of security of a company, B2B tech

Harshil Parikh:

company. So, as a part of some of the previous roles I've built

Harshil Parikh:

and scaled security operations programs, software security

Harshil Parikh:

programs, compliance functions, things like that. So, gotten my

Harshil Parikh:

hands dirty in quite a few things. And as a part of that

Harshil Parikh:

journey, we've seen a lot of common themes and issues come up

Harshil Parikh:

again and again. So got tired of a few of them and decided to

Harshil Parikh:

solve them by starting a company. And here we are.

Dr. Dave Chatterjee:

Fantastic. Fantastic. In fact, if you allow

Dr. Dave Chatterjee:

me, I'd like to share with listeners an excerpt from an

Dr. Dave Chatterjee:

industry report. And I think that sets the context for our

Dr. Dave Chatterjee:

discussion quite well. The report says "many information

Dr. Dave Chatterjee:

security engineers don't understand software development,

Dr. Dave Chatterjee:

and most software developers don't understand security.

Dr. Dave Chatterjee:

Developers and their managers are focused on delivering

Dr. Dave Chatterjee:

features, and meeting time-to-market expectations,

Dr. Dave Chatterjee:

rather than on making sure that the software is secure. So your

Dr. Dave Chatterjee:

thoughts, your reactions,

Harshil Parikh:

I would empathic emphatically agree with that. At

Harshil Parikh:

the end of the day, we all are hired to do our specific roles.

Harshil Parikh:

And this is the world of specialization, right? Like, if

Harshil Parikh:

you hire a security engineer, you hire that person to be a

Harshil Parikh:

really, really good security engineer. Absolutely. In the

Harshil Parikh:

challenge with the current world of software development or

Harshil Parikh:

software security or you know, security operations, incident

Harshil Parikh:

response, what have you is that it's a very complex field. To be

Harshil Parikh:

a good software developer, you need to be good at a lot of

Harshil Parikh:

different things. Security is one of them. To be a good

Harshil Parikh:

security engineer, you have to be good at a lot of different

Harshil Parikh:

things, be very updated, be very fresh, technically keep up with

Harshil Parikh:

a very, very dynamic world, there is not enough time to be

Harshil Parikh:

the best security engineer and the best software developer as

Harshil Parikh:

well at the same time. It's not possible, which is obvious,

Harshil Parikh:

right? Now, what we see in the world is software developers are

Harshil Parikh:

very busy. They deal with very complex technical architectures.

Harshil Parikh:

And they know a little bit about security, maybe, but they're not

Harshil Parikh:

the best at it. Right? And same thing, so yeah, I mean, I 100%

Harshil Parikh:

agree, software developers should be and rightly so,

Harshil Parikh:

they're good at software development, not everything

Harshil Parikh:

else. And the same holds for security.

Dr. Dave Chatterjee:

Absolutely. So given your experience in the

Dr. Dave Chatterjee:

field, we have already mentioned why there is a disconnect in the

Dr. Dave Chatterjee:

sense that if I am a specialist in security, and you're a

Dr. Dave Chatterjee:

specialist in software development, I understand my

Dr. Dave Chatterjee:

work very well, you understand yours. And, I'm incentivized by

Dr. Dave Chatterjee:

ensuring the product is highly secure. You are incentivized by

Dr. Dave Chatterjee:

making sure the product has all the functionalities, and it gets

Dr. Dave Chatterjee:

to market on time. So our incentive systems are often not

Dr. Dave Chatterjee:

aligned. That's one of the things that I think is a

Dr. Dave Chatterjee:

challenge or it causes the disconnect. What do you feel?

Dr. Dave Chatterjee:

Yeah,

Harshil Parikh:

I mean, that's, that's a good insight, right? I

Harshil Parikh:

mean, they at the end of the day, we are all humans and as

Harshil Parikh:

humans, we would focus on getting our things done quickly,

Harshil Parikh:

efficiently with a higher quality, like if you're proud of

Harshil Parikh:

your work. So if as a developer, you are focused and incentivized

Harshil Parikh:

by your leadership on just churning out features as fast as

Harshil Parikh:

you can. So that's what the developer would do. If you're

Harshil Parikh:

incentivizing the developers on building fast feature features

Harshil Parikh:

fast, but at a high quality, and you're measuring them on that.

Harshil Parikh:

And that's what they would do, which is push code rapidly, but

Harshil Parikh:

also potentially build at a higher quality because they know

Harshil Parikh:

they're being measured against that. The unfortunate reality of

Harshil Parikh:

our current world is, most engineering leadership does not

Harshil Parikh:

measure developers or does not incentivize developers on

Harshil Parikh:

building high quality code that is also secure, to a reasonable

Harshil Parikh:

extent, right? I doubt if most companies are in the business of

Harshil Parikh:

building the most secure software ever. That's just not

Harshil Parikh:

the reality of the world. So the idea is, how do you find that

Harshil Parikh:

balance of being agile, being fast, but also being able to

Harshil Parikh:

incorporate security to a reasonable extent that works for

Harshil Parikh:

the business? So I think you're right, that incentivization

Harshil Parikh:

structure doesn't exist today. In cases where it does exist,

Harshil Parikh:

for example, whether they are required by regulation or

Harshil Parikh:

required by law, you do end up seeing that outcome, which is

Harshil Parikh:

developers do follow certain security practices, because they

Harshil Parikh:

are forced to do so. So it all goes back to what are the top

Harshil Parikh:

level objectives? What are the incentives towards geared

Harshil Parikh:

towards? And that's the outcome that we would see.

Dr. Dave Chatterjee:

True, very true. Now, what are you seeing

Dr. Dave Chatterjee:

out there in companies? You mentioned about finding the

Dr. Dave Chatterjee:

right balance. Yeah. How are companies, I'm just curious to

Dr. Dave Chatterjee:

know how companies are finding the right balance, what

Dr. Dave Chatterjee:

practices what structures are in place to achieve the dual goal

Dr. Dave Chatterjee:

of quality software that is also very secure? Yeah,

Harshil Parikh:

I think the one theme that we've seen more

Harshil Parikh:

frequently occurring nowadays. over the past few years is, is

Harshil Parikh:

that there's a little bit more buy-in from the development

Harshil Parikh:

leadership or the engineering leadership to actually give

Harshil Parikh:

security it's due course, right? So earlier, are in a lot of

Harshil Parikh:

cases, even today, security was being positioned as the

Harshil Parikh:

responsibility of this one team that sits in the corner of the

Harshil Parikh:

building, and they do everything security, and everybody else

Harshil Parikh:

does their own things. Now the change that we've been seeing,

Harshil Parikh:

and this is partially also because security has become a

Harshil Parikh:

Board level topic has become an Executive discussion topic, so

Harshil Parikh:

companies are being held accountable for breaches there,

Harshil Parikh:

there is much more attention towards it. So the leadership of

Harshil Parikh:

the company, the executive leadership of the company, they

Harshil Parikh:

start focusing on cybersecurity practices, readiness, risk,

Harshil Parikh:

posture, and things like that. So there is a little bit more

Harshil Parikh:

acceptance in the engineering world where the CTO, VP, Engg,

Harshil Parikh:

Director of Engineering, what have you, those technical

Harshil Parikh:

leadership people, they have started to, to ask about it I

Harshil Parikh:

guess, it's not very, very common just yet, we still see a

Harshil Parikh:

lot of friction. But there has been some adoption that, hey,

Harshil Parikh:

security is everyone's responsibility. Let's work on it

Harshil Parikh:

jointly together. We've seen that come up more frequently

Harshil Parikh:

than before.

Dr. Dave Chatterjee:

Okay, that's very encouraging to hear.

Dr. Dave Chatterjee:

In fact, when I was authoring my book, Cybersecurity Readiness: A

Dr. Dave Chatterjee:

Holistic and High-Performance Approach, my research led to the

Dr. Dave Chatterjee:

identification of 17 success factors, a couple of them

Dr. Dave Chatterjee:

centered around creating a We-Are-In-It-Together culture

Dr. Dave Chatterjee:

centered around cross functional participation. Essentially, the

Dr. Dave Chatterjee:

key messages were that we have to get everyone involved towards

Dr. Dave Chatterjee:

creating a high performance information security culture.

Dr. Dave Chatterjee:

From the standpoint of the developers and the security

Dr. Dave Chatterjee:

folks what that meant, are they also aligned? Are they together?

Dr. Dave Chatterjee:

What is an organization doing structurally, so they are not in

Dr. Dave Chatterjee:

a collision path, but they are working cohesively as one

Dr. Dave Chatterjee:

integrated team, working towards a common goal. What that prompts

Dr. Dave Chatterjee:

me to think is to achieve that organizations will have to make

Dr. Dave Chatterjee:

suitable adjustments to their structure, how they build

Dr. Dave Chatterjee:

software, and I believe that's been addressed in the

Dr. Dave Chatterjee:

methodologies that are being pushed forward these days. And

Dr. Dave Chatterjee:

of course, that has to be coupled, supported by good

Dr. Dave Chatterjee:

incentive systems. Right. And once again, you are the expert

Dr. Dave Chatterjee:

in this area. So I look forward to your insights as to what

Dr. Dave Chatterjee:

exactly is going on? Why is it that these teams have to be

Dr. Dave Chatterjee:

separate? Why can't they be fused and work as one team

Dr. Dave Chatterjee:

towards the delivery of a particular product? Just curious

Dr. Dave Chatterjee:

to know

Harshil Parikh:

Yeah, that has been a question for so long

Harshil Parikh:

within this space, right? Like everyone within the the software

Harshil Parikh:

security space, we all expect that why can't just developers

Harshil Parikh:

know how to write secure code, right? Like, why do we have to

Harshil Parikh:

do anything? We can focus on more complex, sophisticated

Harshil Parikh:

problems and developers take care of the basic hygiene stuff

Harshil Parikh:

that they just should. But I mean, unfortunately, that's just

Harshil Parikh:

not the reality. Right? I mean, I think even basic security

Harshil Parikh:

practices, which seem basic to security people, sometimes are

Harshil Parikh:

not followed by the developers, a lot of times it is about

Harshil Parikh:

education and awareness. It's not, it's not always that the

Harshil Parikh:

developers who want to take the wrong decision or don't want to

Harshil Parikh:

address security issues. Most of the times, they actually do want

Harshil Parikh:

to, but they just don't know how to or even if they want to, and

Harshil Parikh:

they know how to, building secure software is sometimes

Harshil Parikh:

much more difficult several times more difficult as compared

Harshil Parikh:

to just getting it done without securities. And now, you have

Harshil Parikh:

given the decision making authority of whether to spend

Harshil Parikh:

more time and energy building something in a secure way, or

Harshil Parikh:

just get done with with the feature that they need to build,

Harshil Parikh:

right. So if if I was a developer, a junior developer,

Harshil Parikh:

for example, yeah, we probably would be obvious to me like, I

Harshil Parikh:

would just get done with my things, if security was so much

Harshil Parikh:

more difficult. So I think it goes back to is security easy

Harshil Parikh:

enough. And obviously, this is a very broad statement with

Harshil Parikh:

security being easy as is a very nebulous statement too. But at

Harshil Parikh:

the end of the day, what we are seeing now in a lot of the

Harshil Parikh:

modern security teams as they make secure path, the easier

Harshil Parikh:

path, right? So from a developer's perspective,

Harshil Parikh:

building something with security or without security is almost

Harshil Parikh:

the same. To give you an example, if I'm writing a new

Harshil Parikh:

application, I need to store secrets. If I store my secret in

Harshil Parikh:

code, obviously, it's bad, I shouldn't do it. But if I had no

Harshil Parikh:

other resource available, it would be incredibly hard for me

Harshil Parikh:

as a developer to go figure out a secrets management system and

Harshil Parikh:

then set it up and start using it before I could do that simple

Harshil Parikh:

job of getting my service deployed. But if secrets

Harshil Parikh:

management system was already made available by the security

Harshil Parikh:

team, so now for me, as a developer, whether I store

Harshil Parikh:

secret in code is the same level of difficulty, or easiness, as

Harshil Parikh:

compared to using a secret management system that's already

Harshil Parikh:

available, obviously, I would choose in a lot of cases, I

Harshil Parikh:

would choose the more secure choice. So I think it's a

Harshil Parikh:

combination of several things, which is developers are not

Harshil Parikh:

really aware of the decisions they should be making security

Harshil Parikh:

is not always easy for them. They're not incentivized to take

Harshil Parikh:

the right decision. They're not incentivized to make the secure

Harshil Parikh:

decision. So this is what makes it really complex. Right? Our

Harshil Parikh:

world is nowhere close to being automated by bots, because it is

Dr. Dave Chatterjee:

Yeah, absolutely. And, you know, as

Dr. Dave Chatterjee:

complex.

Dr. Dave Chatterjee:

you're talking, I'm thinking about the number of patch

Dr. Dave Chatterjee:

releases, and, you know, patch management being such a

Dr. Dave Chatterjee:

challenge for organizations. And I wish we were in a world where

Dr. Dave Chatterjee:

the software development was more secure, or was more robust.

Dr. Dave Chatterjee:

So you don't have to have that many patch releases. I don't

Dr. Dave Chatterjee:

know how you would react to that. But that's kind of my

Dr. Dave Chatterjee:

thinking of this issue at a high level. Moving along, share with

Dr. Dave Chatterjee:

the listeners some best practices for reducing the

Dr. Dave Chatterjee:

disconnect, what would be certain things that folks could

Dr. Dave Chatterjee:

do in their organization within their sphere and scope of

Dr. Dave Chatterjee:

influence?

Harshil Parikh:

That's a good question. One of the things that

Harshil Parikh:

I've seen work really well, in a lot of cases is very make as

Harshil Parikh:

security professionals when we make security, very crystal

Harshil Parikh:

clear, and very binary. So if, for example, on one extreme, if

Harshil Parikh:

we go to a Dev team and hand them a PDF report, or a

Harshil Parikh:

spreadsheet with 1000s, and 1000s of vulnerabilities and

Harshil Parikh:

say, Hey, developer, go do something about this, right?

Harshil Parikh:

That is not a good productive conversation, because they have

Harshil Parikh:

no idea which ones is important, obviously, they don't have the

Harshil Parikh:

resources to fix all of them. So on the other hand, if you go to

Harshil Parikh:

the development team and say, hey, look, these are the, you

Harshil Parikh:

know, 12,356 issues that we found. But I know most of these

Harshil Parikh:

are not really relevant. How about if we fix 100 of them in

Harshil Parikh:

the first 30 days? And then we addressed the next batch of 200,

Harshil Parikh:

in the next quarter, and then so on and so forth. Let's manage

Harshil Parikh:

our risk collaboratively, I'll help you figure out which ones

Harshil Parikh:

are the most important bugs, what is the high priority for

Harshil Parikh:

you? And you tell me whether is this even possible or not

Harshil Parikh:

possible? Right. So I think one angle to this is we should do

Harshil Parikh:

our due diligence on the data and we should help make their

Harshil Parikh:

jobs a little bit easier by providing them ways on how they

Harshil Parikh:

can actually achieve something. But on the other hand, what we

Harshil Parikh:

also see a lot of times is even if you go take that, you know,

Harshil Parikh:

take that list of 12,600 issues down to 100 issues they still

Harshil Parikh:

will say no thank you Right, this could happen. Now in that

Harshil Parikh:

case, a lot of times what happens is then the security

Harshil Parikh:

teams get left with the accountability of it. Because if

Harshil Parikh:

something goes bad, then all fingers go point to the security

Harshil Parikh:

team saying you guys didn't do anything or you, you gals didn't

Harshil Parikh:

do anything. But in that to address that, then we have to,

Harshil Parikh:

we have to fix the accountability of things. Right?

Harshil Parikh:

So it is not the responsibility of the security team to

Harshil Parikh:

remediate risks, because in most cases, they cannot, right. It's

Harshil Parikh:

the engineering team or the developers who need to remediate

Harshil Parikh:

the risk. So if developers or Dev teams are saying, no, they

Harshil Parikh:

cannot, then we basically assign the risk to them. Right. So now

Harshil Parikh:

it's their decision. So what that calls for is a more data

Harshil Parikh:

driven structure of how you manage security, more

Harshil Parikh:

accountability, and there has to be a top down buy-in, of who's

Harshil Parikh:

responsible for what, the security team is responsible for

Harshil Parikh:

understanding the risk, identifying the risk, and

Harshil Parikh:

highlighting it to the right people. But if the people who

Harshil Parikh:

own the underlying risk, which is the folks that are managing

Harshil Parikh:

and building that infrastructure, or software or

Harshil Parikh:

the systems, if they don't want to fix it, then it's really, we

Harshil Parikh:

have to just hold them accountable for it. It's not

Harshil Parikh:

like we can go and patch the things that they own and manage,

Harshil Parikh:

that's just not going to happen. So making security easy for

Harshil Parikh:

them, making it easy for the Dev teams to actually go and

Harshil Parikh:

remediate things that are really important and matter to them,

Harshil Parikh:

but at the same time holding them accountable for their own

Harshil Parikh:

decisions. I think it's it's a two-way things that really help

Harshil Parikh:

us get out of this ditch. And the other day, we were talking

Harshil Parikh:

about this example, like look, we all know that we should all

Harshil Parikh:

brush our teeth a couple of times a day, floss our teeth and

Harshil Parikh:

maintain general dental hygiene. And the dentists are there to

Harshil Parikh:

give us guidance on how to do it easily. And when something goes

Harshil Parikh:

bad, they'll come in and fix it. But if I don't brush my teeth

Harshil Parikh:

every day, or floss my teeth every day, it's not the dentist

Harshil Parikh:

responsibility, right? It's it should be my responsibility. So

Harshil Parikh:

that's how I view the role of, you know, security, where

Harshil Parikh:

security teams are sort of those experts where they can tell

Harshil Parikh:

people like Hey, guys, look, this is important, we need to

Harshil Parikh:

fix this. But at the end of the day, it's your call, and we'll

Harshil Parikh:

we should hold you accountable for it.

Dr. Dave Chatterjee:

You know, I couldn't agree with you more.

Dr. Dave Chatterjee:

You're essentially speaking my language in many ways, because

Dr. Dave Chatterjee:

I've been harping about the top management setting the tone, the

Dr. Dave Chatterjee:

top management, recognizing what's the right approach to

Dr. Dave Chatterjee:

institutionalizing security in the organization. So therefore,

Dr. Dave Chatterjee:

it goes without saying, to me, it's a no brainer that unless

Dr. Dave Chatterjee:

there is shared accountability, shared responsibility, top down

Dr. Dave Chatterjee:

support, unless the performance evaluation system is suitably

Dr. Dave Chatterjee:

modified, unless work structures are suitably redefined. So the

Dr. Dave Chatterjee:

security team and the development team don't work

Dr. Dave Chatterjee:

separately or don't work in isolation that they work as one

Dr. Dave Chatterjee:

cohesive team, unless these measures are taken in a

Dr. Dave Chatterjee:

deliberate manner. And you mentioned about metrics, it's

Dr. Dave Chatterjee:

very important to at least keep track of a couple of metrics

Dr. Dave Chatterjee:

that taps not only into the quality of the product, but also

Dr. Dave Chatterjee:

it's like a stage by stage tracking of how well is security

Dr. Dave Chatterjee:

being infused into the product at the appropriate stages in the

Dr. Dave Chatterjee:

solutions development lifecycle. We're all familiar with the

Dr. Dave Chatterjee:

Agile development methodology. I think that's the right way to do

Dr. Dave Chatterjee:

it. Like you go back and forth. You constantly get feedback. And

Dr. Dave Chatterjee:

the way I see it is this is a great opportunity where the

Dr. Dave Chatterjee:

security team, the software team are working together in an agile

Dr. Dave Chatterjee:

approach where they're constantly reviewing each

Dr. Dave Chatterjee:

other's work, and trying to make the corrections before it

Dr. Dave Chatterjee:

becomes a major problem. Like you talked about receiving a PDF

Dr. Dave Chatterjee:

with thousand some issues, and I'm looking at it and saying, so

Dr. Dave Chatterjee:

from where do I start? So a lot of things needs to be done

Dr. Dave Chatterjee:

differently. But there's a huge need for it. And this brings

Dr. Dave Chatterjee:

back memories of the disconnect between the technology people

Dr. Dave Chatterjee:

and the business people, which was the focus of discussions for

Dr. Dave Chatterjee:

a long time since the late 90s. That how do you reduce the

Dr. Dave Chatterjee:

disconnect between business and IT? I find the same problem

Dr. Dave Chatterjee:

reemerging in the form of the security people and the

Dr. Dave Chatterjee:

development people. So it's the same problem, just a different

Dr. Dave Chatterjee:

context. The challenges are very similar, but it's always good to

Dr. Dave Chatterjee:

get thoughts and insights and feedback from subject matter

Dr. Dave Chatterjee:

experts such as yourself. Once again, going back to our

Dr. Dave Chatterjee:

discussion. when we were thinking about what all we

Dr. Dave Chatterjee:

should be addressing something that came up were the best

Dr. Dave Chatterjee:

practices for building and scale a modern application security

Dr. Dave Chatterjee:

program. So, what are those best practices? And what do you mean

Dr. Dave Chatterjee:

by a modern application security program?

Harshil Parikh:

Yeah. So I think, for far too long, we've

Harshil Parikh:

operated application security as software security in general as

Harshil Parikh:

a fundamentally different phase from development, right. So

Harshil Parikh:

developers would do their job. And then software security or

Harshil Parikh:

AppSec people would come in, perform these tests and

Harshil Parikh:

assessments and file a bunch of tickets, and then assign it to

Harshil Parikh:

developers and get done with it right and hoping that they would

Harshil Parikh:

go and fix it. I hope there's they're still filing tickets as

Harshil Parikh:

compared to giving them a PDF report with 1000 nations, right.

Harshil Parikh:

So that is a very step by step approach, which is probably good

Harshil Parikh:

fit for a waterfall model of development. However, the world

Harshil Parikh:

has moved on since or at least it's in the process of moving

Harshil Parikh:

on. Now. If you have a discrete step off, like, hey, developers,

Harshil Parikh:

once you're done coding, then we'll do all the assessment,

Harshil Parikh:

that step usually doesn't come because development nowadays,

Harshil Parikh:

it's more of an iterative process, right? There's very

Harshil Parikh:

rapid releases, rapid development, rapid deployments.

Harshil Parikh:

And it's micro feature by feature there is microservices

Harshil Parikh:

architectures. There's no more monolithic applications, and the

Harshil Parikh:

rapid delivery of software makes it imperative that security get

Harshil Parikh:

involved in it in a continuous manner. Because if development

Harshil Parikh:

is continuous, deployment is continuous, then security should

Harshil Parikh:

also be continuous. But it's unfortunately not today. So how

Harshil Parikh:

do you how do you make security continuous? How do you make

Harshil Parikh:

security a first class citizen of software development process?

Harshil Parikh:

I think that's what I really mean by modern application

Harshil Parikh:

security program where application security is much

Harshil Parikh:

more native to software development in general. And, you

Harshil Parikh:

know, we've talked about the security in SDLC, we've got

Harshil Parikh:

maturity models, like BSIMM and OpenSAMM. And we've talked about

Harshil Parikh:

shift left for a very, very, very long time. Unfortunately, a

Harshil Parikh:

lot of the shift left conversation has constrained

Harshil Parikh:

itself to running scans and scanning and running a bunch of

Harshil Parikh:

tools and performing assessments. Obviously, it's

Harshil Parikh:

much more than that, right? I mean, software security is a lot

Harshil Parikh:

of things, vulnerability scanning, being one of them. So

Harshil Parikh:

building a security program that is agile, that is fast, that

Harshil Parikh:

works at the same speed as the DevOps teams or development

Harshil Parikh:

teams that are using DevOps processes. I think that's what I

Harshil Parikh:

mean by modern application security program. And the

Harshil Parikh:

fundamental shift in this is, as AppSec people, we have to

Harshil Parikh:

understand how DevOps actually works. What is source control

Harshil Parikh:

system? What is a CI CD system? How do they both connect, how

Harshil Parikh:

does deployment happen? All of those things need to be

Harshil Parikh:

understood really, really well. And then we can build certain

Harshil Parikh:

practices into the SDLC. The one big change is what I mentioned

Harshil Parikh:

earlier, which is now there is no more a single discrete step,

Harshil Parikh:

where developers would stop and say, Hey, security come in and

Harshil Parikh:

do the assessment. Like that doesn't happen. You can do an

Harshil Parikh:

assessment, but that doesn't mean that developers will stop

Harshil Parikh:

building code. So what that means is, before you're even

Harshil Parikh:

able to finish an assessment and give a report back to

Harshil Parikh:

developers, they have already moved on to other things, and

Harshil Parikh:

they're likely not going to come back and address the debt that

Harshil Parikh:

you just found out. So one of the key decision, or the key

Harshil Parikh:

shift in how you build apps like that works really well is is

Harshil Parikh:

what we call a security guardrails right? So it's

Harshil Parikh:

security guardrails, or some people call it paved roads or

Harshil Parikh:

whatever that is, but what it actually means is a set of

Harshil Parikh:

controls, a set of secure defaults that developers should

Harshil Parikh:

follow, right? So now the assumption here is if developers

Harshil Parikh:

are free to build and deploy services and write code the way

Harshil Parikh:

they want, security teams don't have the time to stop them and

Harshil Parikh:

do an assessment and go and ask them to go back and fix it. So

Harshil Parikh:

security takes a proactive approach and says, you can do

Harshil Parikh:

whatever you want, as long as you are working within this

Harshil Parikh:

boundary. You can define those parameters and then say, hey,

Harshil Parikh:

you can only use container images or host images from this

Harshil Parikh:

internal registry like this is the approved blessed image, only

Harshil Parikh:

use that. You can only use secrets if you're using a

Harshil Parikh:

secrets management system. Or you can only use these

Harshil Parikh:

cryptographic standards, or you can only use these cipher

Harshil Parikh:

strengths, right. So security teams define those security

Harshil Parikh:

primitives, which then get applied at developers lifecycle.

Harshil Parikh:

So when developers are writing code, those checks and balances,

Harshil Parikh:

they just happen by itself by automatically. So that's what I

Harshil Parikh:

mean by security guardrails. And that's the type of thing which

Harshil Parikh:

is automating security controls and expectations into the

Harshil Parikh:

developers workflow. That's what helps people scale AppSec really

Harshil Parikh:

quickly and prevent a lot of the vulnerabilities from coming in

Harshil Parikh:

or prevent risk from manifesting itself in production.

Dr. Dave Chatterjee:

I think that's a great approach because

Dr. Dave Chatterjee:

the extent to which you can leverage the power of automation

Dr. Dave Chatterjee:

to allow development to progress at its normal pace, and yet

Dr. Dave Chatterjee:

achieve the goals of security, so you are achieving both the

Dr. Dave Chatterjee:

goals of security and a timely delivery of software. To achieve

Dr. Dave Chatterjee:

those dual goals, you need the power of automation. And that's

Dr. Dave Chatterjee:

good to hear that there are automation platforms that are

Dr. Dave Chatterjee:

being developed and touted that organizations can avail of to

Dr. Dave Chatterjee:

make life a little easier. Right? I'd like to touch upon

Dr. Dave Chatterjee:

another thing that we talked about the other day. And that's

Dr. Dave Chatterjee:

about empowering the AppSec teams so they can focus their

Dr. Dave Chatterjee:

time on more high-level strategic work. I found this

Dr. Dave Chatterjee:

very interesting. Yeah, what exactly what were you alluding

Dr. Dave Chatterjee:

to here?

Harshil Parikh:

Yeah. So I'll give you an example. So I talked

Harshil Parikh:

to a lot of AppSec engineers almost every week. And my

Harshil Parikh:

intention behind those conversations is just to learn

Harshil Parikh:

how do they do their job, right. And the idea is for me to

Harshil Parikh:

understand that deeply so I can make their life easier. What we

Harshil Parikh:

discovered is a lot of these AppSec teams, their primary job

Harshil Parikh:

is to run assessments, run scanning tools, and let's just

Harshil Parikh:

face it, you know, scanning systems exist in every single

Harshil Parikh:

AppSec team, they produce a lot of findings, but not all of it

Harshil Parikh:

is useful. So a lot of the AppSec engineers, there's just

Harshil Parikh:

doing busy work, taking findings from different scanning systems,

Harshil Parikh:

understanding what it actually means, triaging it, prioritizing

Harshil Parikh:

it, filing JIRA tickets, tracking it bringing people on

Harshil Parikh:

emails, or slack or Microsoft Teams, or what have you,

Harshil Parikh:

following up on it, all of it is ditch digging work, right? It's

Harshil Parikh:

very manual work, it's, it's the work that is actually not

Harshil Parikh:

security work, right as filing tickets and following up with

Harshil Parikh:

people, a lot of security engineers actually ended up

Harshil Parikh:

doing that, because they are focusing on you know,

Harshil Parikh:

vulnerability management or using the scanners to do

Harshil Parikh:

something. Those are the things that should be and can be

Harshil Parikh:

automated, and at Tromzo we've spent a lot of time automating

Harshil Parikh:

those manual processes. So then the security engineers can

Harshil Parikh:

actually focus on doing some security engineering work, which

Harshil Parikh:

is focused on more higher order strategic problems. So let's,

Harshil Parikh:

let's figure out the complex security holes that might exist

Harshil Parikh:

or the complex bugs that you just have seen being discussed.

Harshil Parikh:

And is your organization affected by that. So spending

Harshil Parikh:

more time in real security work as compared to filing tickets

Harshil Parikh:

and following up with people and sending emails and sending

Harshil Parikh:

reports and stuff like that, like that should be automated.

Harshil Parikh:

So that's what I really meant. And there are systems and tools

Harshil Parikh:

available to automate that manual work. It's just hasn't

Harshil Parikh:

taken a wide adoption within the industry. Just

Dr. Dave Chatterjee:

Fantastic! Harshil, it's been such a

Dr. Dave Chatterjee:

pleasure talking with you. I think you shared some very

Dr. Dave Chatterjee:

interesting insights for our listeners. But I'd like to give

Dr. Dave Chatterjee:

you the opportunity to put it all together and wrap it up for

Dr. Dave Chatterjee:

us. So what are your final thoughts?

Harshil Parikh:

Yeah, so it's always difficult to wrap

Harshil Parikh:

interesting conversation into a final sentence. But look, the

Harshil Parikh:

reality is, we are all as software security people, as

Harshil Parikh:

security people, we are faced with this major transformation

Harshil Parikh:

that is happening within the technology space in our

Harshil Parikh:

companies, with more adoption of cloud, with faster development

Harshil Parikh:

cycles and releases, there is no choice for security other than

Harshil Parikh:

automation, like we just have to automate things. Otherwise, we

Harshil Parikh:

will not be able to keep up we are already not able to keep up

Harshil Parikh:

with it. And automation has to be smart automation. And every

Harshil Parikh:

single AppSec team or every single security team is

Harshil Parikh:

struggling with almost the same types of problems, not 100%

Harshil Parikh:

same, but it's very similar. So we don't have to reinvent the

Harshil Parikh:

wheel. So we have to think about these problems in terms of how

Harshil Parikh:

do we scale our security organization. It's not like we

Harshil Parikh:

are going to magically create hundreds of 1000s of security

Harshil Parikh:

professionals all of a sudden, so we are already facing a

Harshil Parikh:

talent shortage. How do we solve that talent shortage problem?

Harshil Parikh:

How do we scale ourselves? And the answer is automation.

Dr. Dave Chatterjee:

I love it. So let me add my two cents to

Dr. Dave Chatterjee:

that. So essentially, if I could summarize what we talked about,

Dr. Dave Chatterjee:

at a high level, I'd approach it using the lens of people,

Dr. Dave Chatterjee:

process, and technology. You already touched upon how

Dr. Dave Chatterjee:

technology can be leveraged to automate certain tasks that

Dr. Dave Chatterjee:

don't deserve too much human time. So humans can focus on

Dr. Dave Chatterjee:

something more valuable, more strategic. But we also talked

Dr. Dave Chatterjee:

about from a process standpoint, how important it is to ensure

Dr. Dave Chatterjee:

that the security teams, the app development teams, are working

Dr. Dave Chatterjee:

in alignment, are working cohesively, are working together

Dr. Dave Chatterjee:

hand in hand, whereby they are not in conflict, and that

Dr. Dave Chatterjee:

process has to be supported by an appropriate incentive system

Dr. Dave Chatterjee:

in place. So the performance evaluation system must be

Dr. Dave Chatterjee:

suitably modified with the blessings of top management, and

Dr. Dave Chatterjee:

finally, people, people still are the most important part of

Dr. Dave Chatterjee:

the equation. I couldn't agree with you more that we absolutely

Dr. Dave Chatterjee:

need technology to help us with security. But still, there's the

Dr. Dave Chatterjee:

people who still make everything run, they are the ones who are

Dr. Dave Chatterjee:

building the technology who are using it. So to enhance their

Dr. Dave Chatterjee:

level of awareness, to provide them the right training, to make

Dr. Dave Chatterjee:

sure they are at the leading edge of things, that's a

Dr. Dave Chatterjee:

constant pursuit of any forward thinking organization. So I hope

Dr. Dave Chatterjee:

discussions such as this inform, influence, inspire management to

Dr. Dave Chatterjee:

take the necessary steps or they might find validation in what

Dr. Dave Chatterjee:

they're already doing. And so I'd like to thank you and your

Dr. Dave Chatterjee:

peers for all the great work that you do in the software

Dr. Dave Chatterjee:

development and security community to keep us as safe as

Dr. Dave Chatterjee:

possible. It's been a real pleasure, Harshil. Thanks again

Dr. Dave Chatterjee:

for joining me for a chat.

Harshil Parikh:

The pleasure is all mine Dr. Dave Chatterjee,

Harshil Parikh:

thank you so much for having me here.

Dr. Dave Chatterjee:

A special thanks to Harshil Parikh for his

Dr. Dave Chatterjee:

time and insights. If you like what you heard, please leave the

Dr. Dave Chatterjee:

podcast a rating and share it with your network. Also,

Dr. Dave Chatterjee:

subscribe to the show, so you don't miss any new episodes.

Dr. Dave Chatterjee:

Thank you for listening, and I'll see you in the next

Dr. Dave Chatterjee:

episode.

Introducer:

The information contained in this podcast is for

Introducer:

general guidance only. The discussants assume no

Introducer:

responsibility or liability for any errors or omissions in the

Introducer:

content of this podcast. The information contained in this

Introducer:

podcast is provided on an as-is basis with no guarantee of

Introducer:

completeness, accuracy, usefulness, or timeliness. The

Introducer:

opinions and recommendations expressed in this podcast are

Introducer:

those of the discussants and not of any organization.

Chapters

Video

More from YouTube