EP#74 – Harshil Parikh – Bridging the Gap Between Security & Development Teams

Time-Stamped Transcript

This transcript was generated primarily by an automated voice recognition tool. Although the accuracy of the tool is 99% effective you may find some small discrepancies between the written content and the native audio file.

Narrator (Intro/Outro) (00:06):

You’re listening to The Virtual CISO Podcast, a frank discussion providing the best information security advice and insights for security, IT and business leaders. If you’re looking for no BS answers to your biggest security questions, or simply want to stay informed and proactive, welcome to the show.

John Verry (00:26):

Hey, there. Welcome to yet another episode of The Virtual CISO Podcast. With you as always, your host, John Verry. And with me today, Harshil Parikh. Did I say the last name right, Harshil?

Harshil Parikh (00:37):

Yeah, you did. You did.

John Verry (00:38):

That was pretty good. How are you today?

Harshil Parikh (00:41):

I am doing great. It’s an absolute pleasure to be here.

John Verry (00:45):

Yeah. Yeah, I’m looking forward to the conversation. Always start simple, tell us a little bit about who you are and what is it that you do every day?

Harshil Parikh (00:53):

Okay. All right. So as you said, my name is Harshil Parikh, and I’ve recently started a company in the application security space. But before that, I spent quite a few years doing different things within the space of cybersecurity. So I started off as a network security engineer back in the day, racking and stacking firewalls and SSL VPNs and so on and so forth. Then eventually, I moved away from consulting and joined the corporate world and building security programs and whatnot. Most recently, I was heading security at a company called Medallia, which is a B2B SaaS company based out of the Bay Area. It was a fascinating journey over there. And since then, having lived through a lot of the pains in AppSec, application security world, we decided to start a company. So now, day to day, my world looks very different than a traditional security operator. But it also keeps it interesting as well. So yeah. Nowadays, it’s more about running the business rather than building a security program.

John Verry (01:58):

Before we get down to business, I always ask, what’s your drink of choice?

Harshil Parikh (02:02):

My drink of choice. Oh my God. Okay. So usually, I’m a beer person. And just yesterday actually, I had one of my favorite beers really fresh out of tap. And it’s Old Speckled Hen. It’s an English beer. Typically, it’s a nitro beer, so it’s more creamier than the usual carbonated beer. But-

John Verry (02:24):

Usually when it’s nitro, is it a stout?

Harshil Parikh (02:26):

It is. It is. Yeah, it is. I mean it’s an English beer and it’s gotten fascinating history to it as well, but it’s a very nice multi-flavor to it.

John Verry (02:37):

Yeah. It’s really funny because I mean you’ve got the ESBs, and I’ve drank a number of those, like Fuller’s ESB out of England, and then also Samuel Smith, they’re one of the classic. Their Oatmeal Stout is a wonderful one. That is Speckled Hen, is that what you called it?

Harshil Parikh (02:53):

Yes, that’s right. Old Speckled Hen.

John Verry (02:55):

All right. I’m going to look for that one. You just enlightened me on something there.

Harshil Parikh (02:59):

All right.

John Verry (03:00):

All right. So thanks for coming on today. The idea behind today’s podcast is for a while, right, there’s been this inherent, I’m going to call it a conflict between security and the development team, right? And it makes sense, right? Because development is focused on time to market and getting features into the product. And security is something that sometimes is perceived as a speed bump and certainly at points can negatively impact them, especially if they don’t do a good enough job of moving security far enough early enough in the process. So how much have you seen today’s shifts in development towards agile development, methodologies and DevSecOps, and these concepts of continuous integration and continuous development? How much has that exacerbated the issue in your opinion?

Harshil Parikh (03:50):

Yeah. I think in a way, it has exacerbated this situation because of the rapid pace of development. And earlier when software deployments would take time, as security people, we had the opportunity and the time to get in there to catch things on time and at least intervene and at least make sure that risk is managed effectively. But now, before you know, before the security person knows, the code has already moved from some developer’s laptop into production in cloud, right? So it’s not enough time. So definitely, it has made things worse. But the good thing about this is the way the whole DevOps workflows and DevOps processes and cloud transformation is going is it actually presents a much bigger opportunity for us as security people to get involved in this process in a much more effective way. These things would never have been possible for us to do because now, everything is as code, right?

Harshil Parikh (04:53):

So you’re going to actually see things as things are getting deployed, you have the ability to build checks and balances into the system. So in my view, security teams who haven’t caught up to this type of shift in how software is being built and developed, they’ve lost out on this. They’re missing the opportunity to build an even better security function. But definitely if you don’t do that, if you don’t keep up with how engineering is moving, then it definitely is a worse situation to be in as compared to before.

John Verry (05:29):

That’s an interesting perspective. So I think what you’re saying is despite the fact that there’s more complexity to the development process from a security person’s perspective, there is inherently in this new model a lot more visibility if we invest the energy into getting to the point where we can gain that visibility.

Harshil Parikh (05:55):

Yeah, exactly. That’s exactly what it is.

John Verry (05:58):

That’s a really interesting perspective I’ve never thought about. That’s cool. Would you say that that same truth or that same concept holds for folks in compliance? Because there’s again, developers also have a little bit of a challenging relationship with compliance as well.

Harshil Parikh (06:16):

Yeah. Yeah, for sure. I mean I think to an extent, a lot of the compliance controls can now be automated. So things that earlier… And I’m not saying 100% compliance can be automated, but a vast majority of it. So for example, even simple things like access permissions and so on and so forth, or even the access that cloud gives us as security professionals or compliance professionals, we can interrogate the infrastructure just using APIs very rapidly in a real time manner, right? So we can automate a lot of these compliance controls now as compared to a more traditional infrastructure where such information was not available via an API. So carrying over the same phenomenon in the software world, developers moving into CI/CD and DevOps workflows, a lot of these data points are accessible using APIs and can be automated.

John Verry (07:15):

Right. So what you’re saying is that instead of actually having to conduct audits or manually going to look for artifacts, we’re in a situation in the compliance world with with the right APIs, that information is available to us through a technical auditing method.

Harshil Parikh (07:33):

Exactly. Yeah. So if someone goes in with the expectation that, “I need to stop the development, I need to perform a manual compliance assessment, I need to perform an audit before somebody can ship code,” well that’s obviously going to fail. You can’t do that. But now, what you have is you don’t need to do that manual audit. You don’t need to do that manual assessment. You can just automate that, right? To an extent using the available infrastructure.

John Verry (07:58):

Yeah. Okay, cool. So in terms of this, from a developer’s perspective, because you know a lot about developers, you work a lot with developers, is the problem deeper than just security getting in the way of schedule? Is there a knowledge gap on the security team side? Is there a knowledge gap on the developer side? Is it not a knowledge gap or is it a knowledge gap and a communications gap, right? Is it technology gap? Is it process gap? Is it all of these? Where is this inherent challenge? Because if we don’t understand what the challenge is, it’s hard to figure out how to fix it.

Harshil Parikh (08:35):

Right, right. Yeah. I think that’s a really good question. And if I really think about it, from a developer’s perspective, I’ll just talk about that perspective first, they have more things than ever before to do, right? Even earlier before DevOps was a thing, we had armies of QA engineers and test engineers and developers would write code and somebody else would test it, deploy it. There would be a separate operations team. They would do the operational maintenance and all of that stuff. But now, developers do all of that, right? They maintain it, they manage it, they operationalize it, they deploy it. It’s the developer. So they are having their expectation from them for the developer role is that they do a lot more than before, now, which implies that they cannot be experts at everything. And hence, they cannot be experts at security either.

Harshil Parikh (09:23):

They should know the basics, they should know the fundamentals, the reasonable amount of security, but we should not expect them to know the most sophisticated security aspects. That’s our job, right? That’s security people’s job. But at the same time, what I’ve seen a lot of the times is security professionals, we tend to focus a lot more on the technical aspects of security as compared to the business aspects or the development aspects. So I think what we have today is a lack of context, the lack of knowledge within the developer community about security and within the security community about the business context, about what is actually important from a development perspective. Lack of empathy is also one of those things that I’ve seen quite a bit across both sides, right? It’s not just-

John Verry (10:11):

Exactly.

Harshil Parikh (10:13):

Yeah. And this leads to a bunch of other things, including the gap of communications because people don’t want to talk to each other. They don’t want to talk freely. There’s a lot of finger pointing and there’s a lot of blame game going on here. So I think that this leads to a lot of the friction that we see in most organizations.

John Verry (10:29):

So that was an interesting answer because I think what it means is that we have a lack of knowledge on both sides of the fence. That lack of knowledge on both sides of the fence leads to communications challenges, right? And without the knowledge on both sides of the fence and without good communications, we’re certainly going to have both technology and process gaps.

Harshil Parikh (10:52):

Right.

John Verry (10:52):

So it’s some combination of all of that.

Harshil Parikh (10:54):

Yeah.

John Verry (10:55):

Unfortunately.

Harshil Parikh (10:55):

Yeah. One thing that I know is that we don’t have a technology gap.

John Verry (10:59):

Wow. Okay. Now, you’re ruining the surprise. Don’t ruin the surprise, we’ve got it wrapped in a bow.

Harshil Parikh (11:06):

All right.

John Verry (11:07):

So quick question for you though there, because there’s an interesting question that I haven’t really asked anyone prior. So again, I like your thought process that developers have a lot more in their plates than they used to. In the agile higher fast-paced world, what’s happened to what used to be the UAT, QA type testing that used to take place? Are there processes that people are using to automate that? Is if the Dev cycle’s so fast, we’re getting that feedback from clients? What’s going on there?

Harshil Parikh (11:42):

Yeah. So that exists, right? It happens today. It’s just done differently. So instead of developers writing code and throwing code over the wall to some poor QA tester who would have to go through a bunch of things repetitively, all of that is automated. Now, if you look at continuous integration, continuous deployment systems, for example, Jenkins or CircleCI, some of those systems, that’s exactly what they do. They take code when it’s ready. They automate a lot of the tests. There’s a lot of testing frameworks that do exactly the same things that humans used to do. But now, it’s just automated and it’s done very, very rapidly in a repetitive manner all the time continuously, right?

John Verry (12:24):

Okay. So if I think back to the old days of… What was it called? Mercury I think was what a lot of people did their testing with, it’s now taking Mercury, bringing it forward and putting it into the pipeline.

Harshil Parikh (12:35):

That’s right. Yeah. Yeah, and developers rely on it all the time, right? So earlier, we used to have change management boards and they would look at things like… Well I mean I think those still exist in a lot of places, but the function of those would be to look at what tests have passed, what tests are failing and approve releases and so on and so forth. All of that is automated now, quite a bit of that is automated now. So now, within a CI/CD system, a release management person or someone can set up thresholds saying, “Hey, these are the tests that your release needs to pass.” Once it passes those tests, you can automatically deploy that. You don’t have to talk to a human, you just go forward with it. But if you don’t pass these tests, then you’re not allowed to move forward. It doesn’t matter who you are. But you’re not allowed to move forward if you don’t meet that threshold. So it’s become that policy as code in a way within the CI/CD systems.

John Verry (13:34):

So we talked about these challenges, right? So if you were chatting with a client or a potential client and we were talking about these issues, right? The knowledge gap, the communications gap, the process gap, technology gap. What would be your recommendations to somebody on how to close those? If I said, “Hey, I’m experiencing all the things you talked about on the podcast in my company,” how do I close those? What would you advise them to do?

Harshil Parikh (13:59):

Yeah, that’s a good question. And these things are really hard as well, right? I guess as you know, this thing is incredibly hard. I mean I think one of the most important things is to build that culture of security and it sounds very nebulous to a lot of them. So I used to wonder all the time, what does that even mean, build a culture of security? Tactically, what is it, right? Is it just everyone should take a security training or everyone should nod their heads and say, “Yes, security’s important?” What exactly does it mean, right? But it’s very nuanced obviously, depending on what company it is and what your business objectives are.

Harshil Parikh (14:36):

But really having a top down buy-in that, “Yes, we are going to invest in security as a company, we are going to spend time in resources and prioritize security all the way from the top leadership to the individual engineers who are working on these codes,” and having that understanding that, “Yes, this is important,” I think that is one of the single biggest things that has the most impact in my opinion, having that buy-in that, “Yes, we are going to invest in security.”

John Verry (15:07):

Is that as simple as I see some organizations where just ensuring that in each sprint, in each story that security is part of that, right? That that’s specifically in there?

Harshil Parikh (15:19):

It could be, it could be one of that. Or even thinking or integrating security in the process of how things are done, right?

John Verry (15:26):

Mm-hmm (affirmative). Or both ideally.

Harshil Parikh (15:28):

Or both. Right, exactly. So not having to wait until some person from security will come and tell you, “Hey, you need to do these five things and then we will prioritize.” So rather than that, how do you proactively build security? So when you’re thinking of a feature, designing of a feature, have a conversation with the security person and just ask them, “What do you think? Do we need to do something different?”

John Verry (15:49):

Right. Right, yeah. Other good things probably like some security training for developers is never a terrible idea. Leveraging open trusted framework, something like OWASP, right? Making sure your developers know about the application security verification standard, right? Inherently, that’s going to get them thinking in that right direction.

Harshil Parikh (16:06):

Yeah.

John Verry (16:06):

And probably, that’s going to drive them to insert these milestones, right? Insert the tools into the right places to achieve the milestones that we’d ideally like to get there. Now, you also have a technical… I mean Tromzo actually has a solution directly as well. So what is it that you guys are doing for organizations to help them close this gap?

Harshil Parikh (16:27):

Yeah. And I mean before I talk about exactly what we’re doing, and I think there’s a big challenge here, which is when we talk about these frameworks, like OWASP standards and ASVS and so on and so forth, when we say they should know about it, we inherently assume that they should remember each and every one of those things as they’re writing code.

John Verry (16:47):

Mm-hmm (affirmative).

Harshil Parikh (16:48):

But that is incredibly hard to do, right?

John Verry (16:50):

Mm-hmm (affirmative).

Harshil Parikh (16:52):

If you look at ASVS, there’s so many controls in that, right? It’s almost impossible for a developer to know about all of them. So in my opinion, knowledge and training, it doesn’t really scale very well. There should be obviously basic understanding, the fundamental table stakes have to be covered in terms of secure practices. But when you talk about comprehensiveness and ensuring that everyone is writing code up to spec with ASVS so on and so forth, my belief is that it has to be codified. It has to be made foolproof in a way that if you’re actually giving them guardrails of like, “Hey, these are the ASVS standards,” for example, secure coding standards.

Harshil Parikh (17:35):

And you don’t have to remember all of it. You should know them, but we codified them in a policy way, right? So if you’re going off of it, we’ll bring you back saying, “Hey, this is a control. You should write your code and so on this way or the other way.” So basically, how do we make this easy for the developers so they don’t have to be an expert in security, so they don’t have to remember hundreds and hundreds of controls?

John Verry (18:03):

Yeah. And it can be as simple as… So as an example. Yeah. I play around a bit in Python for some side projects that I work on just so that I can talk at least semi literally to developers. And in the IDE that I use, the integrated development environment, right, where I’m actually writing code, just for the people. I know you know what that means. For other people, IDE might not mean something. I was really impresses because it automatically alerts me when even just the way I’m formatting my code is going against an established standard for Python.

Harshil Parikh (18:38):

Yeah.

John Verry (18:38):

Right? So that’s the thing that you’re talking about is, right, if we integrate the right tools into the environments that our teams are working on, if we insert the right validation tools and processes into our workflows, right? That’s the thing that you’re talking about to ensure that they have the general knowledge of, “Hey, we need to do error handling in certain ways. We need to make sure that our third party libraries go through the proper validation procedures. We’ve got to handle authentication and authorization and logging in certain ways.” But then we’re going to validate, we’re going to use a tool to enforce that as the code works its way towards production.

Harshil Parikh (19:19):

Right. Yeah. Yeah, exactly.

John Verry (19:22):

Okay.

Harshil Parikh (19:22):

Yeah, exactly. And the simpler and the easier you can make, the better it is, right? So developers don’t have to contact switch a lot. I mean even from a security perspective, if you think about all of the things that we do as security professionals, there’s architecture reviews, there’s threat modeling, there’s static analysis, dependencies, checks and container scans and infrastructure as code scans and dynamic testing and manual pen testing and bug bounty. There’s just so many things. It’s almost impossible for a developer to know even half of those things, right? So how do you make it simple enough so they don’t have to be an expert in those things? But the inherent frameworks, they just take care of a vast majority of those things, the simple things, right?

John Verry (20:07):

Yeah. I like your thought process of trying to make developers’ lives a little bit easier because coding is a complex, you need to get into a zone. And every time that you switch context, right, it can take you somewhere between 15 seconds and five minutes to get back to where you were, right? And not that we don’t want our developers to be cognizant of security, but if you do make them context switch to security, we’re losing a lot of productivity.

Harshil Parikh (20:35):

Right. Right. Yeah. And in my previous lives when we used to work with developers, every once in a while, they would come back and complain about it. They were focusing on writing their code, pushing it, meeting the customer deadline. And then the security tool gave them 76 different CVEs that they need to go and fix. And they have no idea what even CVE stands for.

John Verry (20:56):

Mm-hmm (affirmative).

Harshil Parikh (20:57):

They don’t need to know honestly, but it’s just that it could be a simple fix like, “Hey, upgrade these three libraries and you’re done,” right? You don’t have to worry about it. But unfortunately. The way most of our security tooling is structured is it focuses and glorifies the volume of findings and the more number of things that we find, the better it is, the better the tools justify their value, right? So it’s unfortunate it works against getting developers to buy into it.

John Verry (21:24):

Yeah. Well that’s because we get paid by the page as consultants. You didn’t realize that, Harshil?

Harshil Parikh (21:29):

I’ve spent enough time doing security consulting and I know that very well as well.

John Verry (21:35):

No, no. But that is the terrible thing though, right? And it’s really funny because actually, we make a conscious effort to reduce the number of pages and reduce the amount of data that we actually provide because I think in most cases, it’s overwhelm, right? How do we simplify this down to a point where somebody who is not a security expert can take the end issues that need to be addressed and get them addressed in the simplest way possible?

Harshil Parikh (22:00):

Yeah, totally.

John Verry (22:01):

All right. So where’s the big reveal? Tromzo’s going to solve all of the world’s problems with software development, right? So explain how that happens.

Harshil Parikh (22:11):

We’ll try to. What we’re focusing on is exactly this problem statement that we have been talking about, right? How do we build a bridge between security and developer community? So we make security a first class citizen in the developer workflows, right? How do we get us a seat at the table? And for that to happen, we’ve spent a lot of time looking at all of our security practices from a developer’s perspective. How do you make it easy for them? How do you make it seamless? And obviously from a security perspective, their role is shifting in a way, because as we talked about earlier, if you’re moving away from manual processes into automated checks and balances, how do you automate the traditional processes and controls that used to be very manual controls? How do you trigger certain things? How do you validate compliance controls and so on and so forth in an automated fashion? So we’re building a lot of these automated security controls that integrate in the developer workflows to help you scale application security.

John Verry (23:18):

Okay. So Tromzo is a platform that makes it simple to connect all of this information and manage all of this information and tools, is that the idea?

Harshil Parikh (23:33):

That’s exactly what it is, right? And the key thing here is you can automate a lot of the security activities and processes if you have the right context, because if you apply the same level of security across every single thing that your developers are working on, that’s going to be a massive overhead for a lot of people. So we bring the right context together, meaning which code repo is actually important? Which services are actually deployed in your cloud in production? Versus which things, which codes, services, containers are just internal or testing or staging and so on and so forth? So bringing a lot of that distinction between who owns what parts of code and which one is actually important allows you to automate a number of these things.

Harshil Parikh (24:22):

So going all the way from the first step of software development life cycle when architecture is being built and designs are being built. So for the relevant aspects of software development, you can trigger things like threat models and architecture reviews, and automate a lot of the security testing. And once you get findings and you can prioritize in an automated fashion because you have all of these context, the business context within that platform. And then if you put all of these things together, what you get is an AppSec management platform.

John Verry (24:57):

Got you. So I like what you said about context, right? And so what context I guess allows you to do is it allows you to increase the signal to noise ratio of all of the tools and information that are providing us information about our software development process?

Harshil Parikh (25:19):

Right. Yeah. Yeah, and it allows us to build the right level of security so they work on right things. So I’ll give you an example. In my previous life, in my previous job, we had 500 software developers across the globe. And everyone would obviously be working on either new features or buck fixes writing code every single day, right? And they would push to production very, very quickly. But how do you know out of all of those stories [inaudible 00:25:48] that they’re working on, how do you know which one is actually important? How do you know as a security person which ones do you need to look at and review or work with developers on? It’s really, really hard to do that. So for that, you would need context. So we had an application security team that would deeply understand the different products and services being built. They would work with product managers and project managers to understand who’s working on what and what needs a security review.

Harshil Parikh (26:14):

But we could automate all of that stuff, right? Because we know what code repo is going where, and what is a product being built? What is the business unit? Who owns it? When you bring all of that context together, you can automate a lot of these decision. If you are deploying in a compliance control environment, like a FedRAMP environment for example, then you need to go through these seven other checks and balances, and you can automate a lot of these checks and balances. And you can automate a lot of these policies saying you cannot open an S3 bucket without approval. If you are going in this direction, you cannot include a library that has a critical vulnerability in it if you’re deploying in FedRAMP environment, right? So you can make certain policy statements and automate these policy statements through a platform like us.

John Verry (27:00):

So a lot of the people that listen to the podcast are more information security people, perhaps in addition to being application security people, but definitely InfoSec people. So when we talk about that context and that prioritization, as an information security practitioner, we always take a risk-based approach. Is the threat modeling, which is the risk assessment equivalent in the application security process, is that what you’re using to prioritize which pieces of the code are going to be most relevant, right? Because we know that, let’s say, a particular portion of the code that deals with either credit card numbers, or personally identifiable information, or patient health information, or authentication authorization is going to be more important than something which has something to do with just presentation layer. Is that how you’re contextualizing and prioritizing things?

Harshil Parikh (27:49):

Yeah. That’s definitely a core part of it, right? And we look at contextualization prioritization with two different angles. One is how do we bring the business context? Which is exactly coming from a risk assessment like are you building a service for a customer facing environment? Or is this an internal system for marketing and calendar invites or whatever, right?

John Verry (28:12):

Mm-hmm (affirmative).

Harshil Parikh (28:13):

So that’s bringing the business context of what the actual piece of software will do to your business. And the other aspect is the security aspect. So things like when you have a dependency that is vulnerable, is there even a fix available? If there is no fix available, you can’t really do anything other than understand that there is risk. It’s not actionable at that time. Is the CVE or is the issue even exploitable?

John Verry (28:37):

Mm-hmm (affirmative).

Harshil Parikh (28:39):

There’s a lot of vulnerabilities that would be very, very highly rated from a severity perspective. But a lot of times, if you really look at it, they’re actually not exploitable. And so those things should be considered in terms of how you prioritize things. So we bring the business context together along with the security context so you can make the right decision.

John Verry (29:01):

Makes sense. So when you deliver Tromzo, are you guys delivering it… It sounds to me as if it’s an integration of tools, technology, process, but it does seem like it needs a guiding hand of significance, right? Right? So is somebody buying the platform and they’re implementing the platform themselves? Are you guys providing a managed service on top of the platform? How does that work?

Harshil Parikh (29:28):

Yeah. So I wouldn’t call it a managed service, but we do have a white glove onboarding service for our customers, right? So we just spend a little bit of time with them helping them get onboarded. But then after that, it’s just self-service for our customers.

John Verry (29:41):

Okay.

Harshil Parikh (29:41):

It’s fairly simple to use because I mean it’s relatively easy to make policies that can be customized, right? So we have a lot of policies that come out of the box and then people can just customize on top of it. Our intention is to make it as lightweight as possible for our customers, right? So it’s just easy to use.

John Verry (29:59):

Got you. Do you find that there’s particular company profiles, use cases, whether it’s CMMC or someone who’s doing payment card industry data security standards stuff, are there any particular use cases where you’re having more success using the platform where the platform provides a greater degree of value?

Harshil Parikh (30:18):

Yeah. I mean what we’ve seen is there’s two categories of companies that are really passionate about solving this problem. One category is people who are just phenomenally proactive security practitioners who have a higher degree of maturity in their application security program. So they just want to get better and better. So they want to measure things. They want to improve it. They want to shift left and automate a lot of these things. So that is one bucket of customers. The other bucket of audiences who have a lot of regulations that they need to comply with. So for example, SOC 2 Type 2 is lightweight, but still FedRAMP compliance is a big one in terms of being able to or having an audit trail for assessing every single change that goes into the environment, being able to prove without a trail that it was assessed.

Harshil Parikh (31:09):

What did you do with the findings and resolving bugs in a reasonable timeframe as defined by [inaudible 00:31:15] so on and so forth. So highly regulated environments also want to get better and better at automation because developers are not waiting for them, for the security people to come around to compliance. So you have to automate a lot of these activities. So that’s also relevant for them.

John Verry (31:35):

Yeah. I’m assuming you’ve looked at the executive order, the presidential executive order, and the software labeling concept. And CISO just put out a document on that. I think that’s going to drive more people to take a more formal approach and leverage tools like yours.

Harshil Parikh (31:52):

Right. Right. Yeah. I think these are all very, very hard challenges to solve, right? And I’m not claiming that we can solve all of them, but this is really a good thing for the security industry in general that we’re bringing more transparency in the entire process end to end.

John Verry (32:09):

Yeah. It makes total sense. So do me a favor if you would, and do this at a business person’s level, because we’ve thrown a lot of language out there and talked about a lot of things. We talked about CI/CD and we talked about agile and we talked about pipelines and workflows. And a lot of these terms sound familiar to people. But take us through an idealized process, right, that someone should have in place. And as you’re doing that, you might point out places where you guys provide value in that process, right? So someone taking a code out of a repository to it being pushed out into their virtual infrastructure.

Harshil Parikh (32:50):

Yeah. I’ll probably start even before getting code into the repository.

John Verry (32:55):

Awesome.

Harshil Parikh (32:56):

Yeah. So let’s start with the first step typically where either a product manager or an engineering manager, an audit developer, they think of a new feature to build and some new code to write. Typically, that comes first, somebody decides, “Oh, we need to do this. We need to build this feature.” Typically, they would think about how to do that. So either it would fit into the existing architecture or are they introducing something net new, right? So during that process, that’s the earliest, ideally the earliest where security should get involved in that process. And I’m not saying the security team should get involved. The process of security should get involved at that time. So a very simple lightweight risk assessment that would say, “Is this feature even an impact? Does this impact anything from a security or risk perspective?” Or for example, if it is changing just a text on a text box or changing color on some web applications page, that has nothing to do with security. You can go forward with it, do your thing. Don’t worry about going through any detailed security assessments.

Harshil Parikh (34:01):

But let’s say you’re introducing a brand new way of authentication and authorization, or you’re changing some cryptographic functions, you should probably do some security assessments, right? So the first part of when you’re thinking or designing a feature is that quick and easy risk assessment of does this need security or no? If the answer is no, go for it, don’t do anything about it. But if the answer is yes, then you have to go through certain other things, like either a manual review or an automated testing. So let’s just take the next step, right? So when you actually start writing code and you know that okay, they have to go through some security checks and balances, meet some security controls. And a lot of those controls should and can be automated during the coding life cycle. When they’re writing code, they’re merging their code into their code repository. A lot of these security scanners can be run in an automated fashion, whether it’s static analysis, or dependency checks, or container scanners, or so on and so forth, so that developers get really quick feedback.

Harshil Parikh (35:05):

So as their writing code, they get to see are they introducing net new vulnerabilities? Or are they introducing supply chain related issues from dependencies they might be using? So quicker feedback to developers before they are done with that code, right? So a lot of times, we wait long to give them that feedback. And by the time, they’ve already moved on to other things, developers have moved on to other things. So ideally, we should give them that security feedback just like the example you were talking about, which is Python coding. And it’ll tell you even for the formatting errors quickly so you can correct it right then and there.

John Verry (35:38):

Mm-hmm (affirmative).

Harshil Parikh (35:39):

So then once you have that, once you’re deploying it into production, or you do some testing in stage or test environment, which really builds your code as one single application, runs more comprehensive tests, that’s another stage where we could do a rigorous security test. Let’s just say for example, dynamic scanning or a manual pen testing, if you want to, you could do it at that time because that’s where your code comes together as a live application and you have a running instance of your application that you can test against. And once all of those tests are passed, then you deploy successfully into the production. I’m probably missing some aspects throughout this life cycle, but this is the basic view of how you should do things.

John Verry (36:24):

Got you. And for those listening, so you hear the term workflow like a Jenkins. So there’s some tool that sits in the middle of this that is going to choreograph this.

Harshil Parikh (36:35):

Right.

John Verry (36:36):

Right? And then your tool is going to interact with these tools and with the Jenkins or whatever is choreographing on their part. And yours is going to apply the logic in, “Hey, based on this level of risk, it needs to go through this type of a scan, container scan or not container scan, dependency scan, not dependency scan, it needs to generate a ticket in this system.” Your logic gets implied throughout that workflow.

Harshil Parikh (37:03):

Yeah, exactly. Exactly. Right.

John Verry (37:05):

That’s pretty cool.

Harshil Parikh (37:06):

We do that. And also, I mean just being a practitioner of the industry, there are also quite a few open source tools that other security teams have built over the past few years that touch onto these topics, right? They’re obviously not as comprehensive, they’re open source tools. But this initiative has been taken within the industry, which is great for the application security space in general.

John Verry (37:30):

Cool. So at Pivot Point, we’re huge believers in aligning our clients with open trusted frameworks. In terms of the type of work that you do, are there any open trusted frameworks that you guys count on and often use to help your clients?

Harshil Parikh (37:44):

Yeah. So I mean a lot of our mature clients, they have either their eyes on BSAM or OPEN SAM, those are standard maturity models. But a lot of our mature clients use that to drive adoption of security practices within the organization. They use that as a north star into where they want to take their security program. So as a security leader, I think it’s incredibly useful to gauge which parts of your business need more care and feeding from a software security perspective.

John Verry (38:16):

Got you. So I would imagine during that contextualization phase, when you first are in that white glove service, one of the things that you’re asking for is a copy of their SDLC or their software development methodology, so that way you can align the way that you implement your product, Tromzo, in accordance with their SDLC.

Harshil Parikh (38:34):

Yeah, that’s right. Yeah. And we don’t do it as a formal practice for every single customer, because not everyone is looking for very high maturity in SDLC.

John Verry (38:42):

Mm-hmm (affirmative).

Harshil Parikh (38:42):

A lot of them are looking for just automation and workflows just to eliminate a lot of the manual ditch digging work that that teams might be doing, right? But yeah, I mean it’s a core part of how we help our customers journey towards more scalable application security.

John Verry (38:59):

Yeah. It’s funny though, isn’t by definition implementing Tromzo maturing their SDLC, right? Because SDLC is just following a defined process repeatedly and what you’re doing is… So in a weird way, they can’t help but mature their software development life cycle methodology when they implement your solution.

Harshil Parikh (39:17):

Yeah. Yeah. That’s exactly what it is.

John Verry (39:20):

Yeah. I think we did a pretty good job of talking this through. Is there anything else that we should discuss here?

Harshil Parikh (39:27):

I mean we touched upon a lot of these topics. And I mean the one thing that I love that I’m seeing in the industry so far are is you see a lot of the traditional developer tools and ecosystems also getting into the space of security, right?

John Verry (39:43):

Mm-hmm (affirmative).

Harshil Parikh (39:44):

So you have companies like some of the more modern application security companies who are saying developer for security, which is great. But at the same time, you have more traditional development tools like GitHub and GitLab. And a lot of those companies, they’re building security products and services. And I just find this as a fascinating time for application security, which is the first time where non-security companies, more traditional DevTool companies are trying to get into security because everyone accepts that security has now become such a mainstream thing. So I’m just looking forward to seeing how the next few years pan out for this industry and how we can get better alignment between how developers do their job and how we can integrate security into their processes.

John Verry (40:27):

Yeah. And I think part of that is the fact that, and you mentioned this earlier and maybe it would be a good thing to define for people, is you talked about infrastructure is code. And I think one of the reasons why you’re seeing it be so much more important is that what used to be hardware is now software. And I don’t think an average listener might even be aware of that. Talk a little bit about what we mean by that where infrastructure is code or where hardware is now software.

Harshil Parikh (40:56):

Yeah. So a lot of this has changed, right? So the initial waves of virtualization and now moving onto the cloud exposing the entire infrastructure, like for example, AWS exposes pretty much anything that you can do on the infrastructure layer as an API. So you write code. Instead of deploying hardware, you just write code in terms of what size of an easy to instance you need and what capacity you need, what compute capacity or storage capacity you need, and they just provision it for you, right? So instead of ordering hardware from traditional suppliers and then racking and stacking it in data centers, now you’re just making an API call to a cloud provider and all of that comes up within a few minutes. So that’s really driving the ease of use for everyone, right? Not just the infrastructure people, but also developers can now spin up infrastructure assets. Earlier, they would have to rely on IT and file ServiceNow tickets before they can get a server provision. And now, it’s make an API call and you got it.

John Verry (42:03):

Right. And if you think about it in the old days, right, not only did you have the IT team involved, but IT or IS was responsible for ensuring the security of the box, right? So they’d be configuring the box on your behalf before you can put your code on it.

Harshil Parikh (42:14):

Right.

John Verry (42:14):

Now, what’s happening is that these developers are effectively the IT and IS guys, right? They’re spinning up this infrastructure. And the Lord giveth and the Lord taketh away. I mean the downside of that is you can spin up… I mean you can spin up virtual data centers, right? I mean the firewalls code, all of the servers code, everything’s virtualized. And that can be scary. The flip side is if you have good control over your code development processes, okay, that can be empowering.

Harshil Parikh (42:46):

Exactly. Yeah.

John Verry (42:47):

Which is why Tromzo and products like yours and people that are trying to do the same thing as you are so important, right? Because if we’re doing it right, it’s awesome.

Harshil Parikh (42:59):

Right. Right. And that’s the generational shift that we are seeing in terms of how security is changing and will be changing, right? And I think it’s a fantastic opportunity for our industry to transform.

John Verry (43:11):

Well listen, I think both of us are going to have a next fun five years or so watching all this stuff develop, right?

Harshil Parikh (43:18):

Yeah.

John Verry (43:20):

So hopefully, you did your homework. I see a little nervousness in Harshil’s eyes, guys. So I’m going to ask you, what fictional character, real person do you think would make an amazing or horrible CISO, AppSec guy, developer, take your pick?

Harshil Parikh (43:36):

All right. So I don’t know if this is the best answer I could give, but I just finished watching the second season of Ted Lasso. Have you seen that show?

John Verry (43:47):

No, I haven’t. That’s on Apple TV, right?

Harshil Parikh (43:53):

All right. Okay.

John Verry (43:53):

But right? That’s on Apple TV?

Harshil Parikh (43:53):

It is on Apple TV.

John Verry (43:54):

It gets rave reviews. Is it that good?

Harshil Parikh (43:57):

It is really good. I mean it’s got a very unique sense of humor to it.

John Verry (44:01):

I like him. I like the lead actor. I forget his name, but I really like him.

Harshil Parikh (44:06):

Yeah. No, he’s fantastic. And the funny thing is at one of our recent Halloween parties, I dressed up as Ted Lasso. And out 30 people, there were six other Ted Lassos. So it’s very common. But anyway, so I think Ted Lasso would make a phenomenal CISO because of his ability to go into a very unknown situation. He had no idea what soccer is all about or football as they call it. But he went in there, he built success upon his ability to establish relationships, to coach people, to mentor people, bring players to their best of their performance. And this is not just about being a good leader, but it’s more about how do you connect to people who don’t represent your background, right? This is very true for security people who have to connect to software developers, network infrastructure people, IT people, finance, sales, professional services, all of them. They have to influence a lot of these different types of groups without having the authority over them, which is the reason I think Ted Lasso would make a phenomenal CISO.

John Verry (45:17):

So it’s amazing. I’ve reported a podcast just recently, it hasn’t been published I don’t believe yet. And the answer somebody else gave, and I had never thought of this, was almost identical to your answer. I think it was Hoover, but maybe I’m mistaken. But they said the same thing is that the ability to manage resources that are outside of your sphere of control-

Harshil Parikh (45:41):

Yeah.

John Verry (45:41):

Is a critical component being a CISO, which is exactly what you just said about Ted Lasso.

Harshil Parikh (45:48):

Yeah. Yeah.

John Verry (45:48):

That’s very cool.

Harshil Parikh (45:49):

Right. That show is amazing. You should watch it.

John Verry (45:51):

Yeah. Look, 9.99 a month, right, so I can watch one show. I mean I guess I could buy it, stream it and turn it off. That’s the problem, and I love streaming TV. I don’t remember the last… Except for sports, I don’t watch any real TV anymore. The only challenge is that there are too many of these services and you can’t get to all the good stuff you want to get to.

Harshil Parikh (46:11):

Yeah.

John Verry (46:12):

Right? Because I’m a Sunny in Philadelphia, have you ever watched Sunny in Philadelphia?

Harshil Parikh (46:17):

Yeah.

John Verry (46:17):

Okay. Well that guy, he has a new show on… Is it Apple? No, it’s not Apple. It’s on I think it’s Disney+ called Mythic Quest or something of that nature. And I’m like, “Ah, I would like to watch that. I’d like to watch Ted Lasso.” And soon, my non-cable TV bill is more expensive than-

Harshil Parikh (46:35):

Yes.

John Verry (46:36):

It’s a car payment at that point when you start to subscribe to all these services.

Harshil Parikh (46:40):

Yes. And full transparency, I actually didn’t buy Apple TV subscription. It came with my laptop. So I have one free year of doing that, and then we’ll see if it makes sense.

John Verry (46:50):

Well listen, I mean if Ted Lasso season three comes out, you’re probably going to want to subscribe. All right, last question. You chat with the same people I chat with every day, any ideas for any things we should cover in a future podcast?

Harshil Parikh (47:08):

I think this infrastructure is code is a very fascinating topic and especially in a world where it’s not just AWS anymore. Azure and GCP, Google Cloud Platform, is also getting really, really popular. So I think it would be phenomenal to talk about what this means for security multi-cloud versus single cloud. So it’s not anymore about on premise versus the cloud, it’s more about is it single cloud or multi-cloud and what does security do in that situation?

John Verry (47:44):

Yeah. And the one that hurts my head when we think about that is when you layer containers, which I’m not as smart as I should be on, when you layer containerization into the picture.

Harshil Parikh (47:54):

Right.

John Verry (47:55):

Because now, you’ve got that same challenge, but you’ve got it like the movie Inception, right?

Harshil Parikh (47:59):

Yes.

John Verry (48:01):

Three dreams down, I’m three VMs down and it’s like, “No. Guys, I can’t fathom this. I need someone to diagram it out for me.” Well this has been fun. I really appreciate you coming on. I think what you guys are working on is critical if we’re going to get our industry back to where it needs to be from a security perspective.

Harshil Parikh (48:28):

Awesome, John. Thank you so much. It was a pleasure.

John Verry (48:31):

Yeah, same here.

Narrator (Intro/Outro) (48:33):

You’ve been listening to The Virtual CISO Podcast. As you’ve probably figured out, we really enjoy information security. So if there’s a question we haven’t yet answered or you need some help, you can reach us at [email protected]. And to ensure you never miss an episode, subscribe to the show in your favorite podcast player. Until next time, let’s be careful out there.