Episode 26
Reducing the Disconnect Between Security and Development Teams
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
Transcript
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.
