When it comes to security awareness, the advice generally doesn’t change. There are a set of best practices that have proven to be effective. So we know what we want to tell people. Communicate it consistently. So how do we relay that information without sounding like a broken record?
This week’s episode is hosted by me, David Spark (@dspark), producer of CISO Series and Steve Zalewski. Joining us is our sponsored guest, Daniel Krivelevich, CTO for Appsec, Palo Alto Networks.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, Palo Alto Networks
Full Transcript
[Voiceover] What I love about cyber security, go!
[Daniel Krivelevich] What I love is that it’s full of industry defining moments happening on a very frequent basis provided mainly by the attackers of the world.
[Voiceover] It’s time to begin the CISO Series Podcast.
[David Spark] Welcome to the CISO Series Podcast. My name is David Spark. I am the producer of said CISO Series. And my cohost for this very episode, it’s Steve Zalewski. You usually hear him over on Defense in Depth. But like one of those Donny and Marie episodes where all of a sudden Marie becomes rock and roll, and Donny becomes country, Steve has made it over to the CISO Series Podcast.
Welcome, Steve.
[Steve Zalewski] Oh, man. How do I answer that? Hey, audience. It’s great to be here. Thank you, David.
[David Spark] We are available at ciso-dev.davidspark.dcgws.com. Our sponsor for today’s episode is Palo Alto Networks. Of course you know Palo Alto Networks. Everyone does. And we are thrilled to have them as a sponsor again. And they’re responsible for bringing our guest today, which I’m very, very excited about because we’re going to have a lot of discussions about application security because this guy is an expert on it.
But before we get there, I do want to mention that today is our last day of a run of six live shows. And the irony is that we’re recording this before the run of six live shows.
But if you’re listening to this and you live in the Bay area or in the Silicon Valley area, the day this drops, which is October 17th, this evening we’re doing a live show in Mountain View at Microsoft’s campus there in Mountain View. So, come see us live in person. This is the part of the ISSA, San Francisco, Silicon Valley meet up event.
And we are essentially the entertainment. If you want to know how to get tickets, which essentially it’s free, just go to ciso-dev.davidspark.dcgws.com, click on events. You’ll find the link for our event, and it’ll take you to the registration page. You will need to do because there’s security, and you will actually have to register.
So, please come. We love doing live shows. Steve, I haven’t gotten you on a live show. I’m going to have to get you on a live show soon.
[Steve Zalewski] Yes, looking forward to it.
[David Spark] We will do it. But now we’re doing a show. It is live in the sense that we’re doing it live virtually but not in front of an audience.
[Steve Zalewski] With half a cup of coffee, so beware.
[David Spark] Aw, good point. All right, let’s bring on our guest right now. This person is the CTO for application security over at Palo Alto Networks. It is Daniel Krivelevich. Daniel, thank you so much for joining us.
[Daniel Krivelevich] Hi. It’s great to be here.
What’s the best way to handle this?
2:51.058
[David Spark] A lot of times, breaches boil down to just a Cloud misconfiguration. But to phrase Tarek Khaled, who is the founding sales engineer over at Veza, misconfiguration is not a simple mistake. It is a systematic problem that leads to a misconfiguration. In a recent post on Medium, Anton Chuvakin, who hosts the Cloud Security Podcast over at Google, laid out why these misconfigurations keep happening, and one major factor comes from IT practices from the 90’s with an emphasis on slow manual approaches, carrying over to the Cloud.
It’s common to chalk all misconfigurations up to human error, but… I’ll start with you, Steve. What do we need to better understand about misconfigurations to better serve the Cloud? Let me ask you, do you think it’s just simple human error, or do you think it’s a systemic problem?
[Steve Zalewski] I think it’s a systemic problem and not just human error because… And I love that the show is going to be about app sec today. Is because I think it’s about ignorance, arrogance, and accidents. Meaning when you look at the developers themselves and the security practitioners or the security vendors who come here to say, “I’m here to help you,” what I really want them to say is I want you to own a problem and take it off your plate.
[David Spark] Good way of putting it.
[Steve Zalewski] And the problem here is the type of developers. And so while humans make mistakes, developers are either ignorant because they don’t know, they’re arrogant because they feel they’re above the law, or they make an accident, and that indeed it was just a human mistake. And from my perspective, I think app sec needs to acknowledge that and figure out how they build around those types of developers to give us the ability to manage those types of perspectives, not just try to make it a technology process adoptions.
[David Spark] Daniel, let me take from what Steve said of do you believe that a lot of this security comes down to how we manage developers and how we essentially work them through the system?
[Daniel Krivelevich] Yeah, so I think maybe it’s worthwhile to take a step back and recognize the fact that we are talking about developers when we are talking about misconfigurations. Because it was three or five years ago when configurations were managed through a settings or a configuration page, not in code.
And today the reality is, as you said, that we have the majority of our system configurations managed through codes or the source control systems which is much easier to handle and maintain and lint, and ensure that it is aligned with our policy. And so that gives us an opportunity to work with developers on maintaining good configuration.
I think what’s missing today is that the security solutions tend to be too noisy, tend to distract developers with configurations that don’t necessarily have the right impact and tend to make security what’s considered by them a nuisance. I think the opportunity there is to leverage the fact that configuration is managed with code and basically build security products that help developers focus their efforts and attention in the places where it matters the most.
I think if we’re are able to do that then we will have a reality where we have much less configuration errors than what the reality is today. So, I think there is a big opportunity there.
[David Spark] So, let’s talk about that opportunity. Give me one example of where you’ve kind of removed that aspect of the irritation to developer and made it less of an irritation, made it something they want to do. Or maybe they don’t even need to do because it becomes automatic. I don’t need you to boil the ocean, but just give me one example of conquering that problem you just set up.
[Daniel Krivelevich] So, it’s basically the essence of shift, left. You’re not managing configuration in a setting page. You are shifting issues to developers in code. So, if reality earlier was that you had some scanner identifying misconfigurations and then flagging them 1, 2, 3, 20 days after the code was written, now we have the opportunity to respond directly to the developer when the code is being written or on the PR that requests modifying the code.
And then the same developer that made the mistake is able to maintain reference the mistake he just made and fix it right away with the right context instead of dealing with it a few weeks later or dealing with a mistake that some other developer made. So, that is the opportunity, and that, for me, is a big part of the essence of shift, left.
[Steve Zalewski] I’m going to take a contrarian view. Not a contrarian, but I’m going to also say it’s shift, right.
[David Spark] And we’ve heard shift with context.
[Steve Zalewski] Well, I’m going to say actually shift right.
[David Spark] Okay.
[Steve Zalewski] Go right of boom is the way people like to talk about it, which was while we want to give the app developers the opportunity to not make a mistake, because we have the ignorant, arrogant, and accident type of developers, we need to go to the right and be the last line of defense for the developers to be able to say when in any of those instances something happens, how do we embrace the sprawl, how do we embrace the visibility and then bring it into alignment rather than trying to force alignment up front.
So, I think we actually have first line of defense and last line of defense opportunity here for app sec that will set us apart from the way we’ve traditionally solved it.
Are we having communication issues?
8:44.780
[David Spark] “What security measures have been the most successful in preventing cyber-attacks,” asked a redditor on the cybersecurity subreddit. Now, a very interesting pretty darn open question, and the response though was enthusiastic with a major theme around basic security hygiene. Many replies advocated for better education of employees and adopting MFA.
The issue is none of these items are new. So, are we a broken record? Even what you were saying in the last segment, Daniel. We’ve heard this stuff before. My big question is how do we change the security narrative around this basic practices to stop people from just glazing over each time it comes up because none of this is new.
What do you think?
[Daniel Krivelevich] I think a lot of breaches are happening because security teams are struggling to know what it is that they’re protecting. I was an incident responder. A lot of the breaches that I’ve been involved with directly or indirectly had to do with a compromised asset that wasn’t part of the scope of governance of security teams.
And that makes sense. With hybrid environments with on prem and Cloud Shadow IT with how fast digital transformation processes are occurring, there is a challenge in governing the estate. And when you have a challenge in governing the estate, it only takes one mistake. It only takes one asset overlooked for an attacker to find an opportunity.
And so you can’t protect everything. You can’t secure everything. But you have to be able to do risk acceptance for everything, and you have to be able to understand…to be comfortable with the fact that you know what it is that you’re protecting, you know where you need to put the effort, and you know where you’re making informed decisions about risk.
And so from my point of view, the room for enhancement is with visibility. With every vertical, whether it’s active directory security, or end point security, or application security, or network security to make sure that they have a full understanding of what it is that they’re protecting to invest proactively in managing the assets and making sure that no asset goes overlooked.
And then understanding where it is that I want to invest in protecting.
[David Spark] So, blame the business! They didn’t communicate to security well enough. Yes? Can we blame the business? It’s never security’s fault, right? I like this. I like this, Daniel. Hold on. Let me hold this thought. I’m not putting those words in your mouth, by the way, because I know you don’t want that coming back to bite you.
Steve? [Laughs] We can’t flat out blame the business, but Daniel brings up a really, really good point of this is a struggle we hear from CISOs all the time. “What am I protecting? What are the crown jewels?” The big joke we make about CISOs and their first 90 days. It’s like they struggle just to figure out what the heck that is.
And nobody all of a sudden on day one goes, “By the way, here’s a sheet of all the crown jewels for you,” handing it on a silver platter. They never do that.
[Steve Zalewski] Correct. I think one thing I’ll say is for app security now, the developers are our business. We’ve got the wrong focus of thinking it’s the line of business, business sponsors. But from this perspective, the developers themselves are our business. And what we keep trying to do with the developers like the business is secure the company, which is we’re introducing an intolerable amount of friction into the enablement of the business versus having this conversation around empowering them and simply saying, “What is acceptable tolerance versus acceptable risk?”
So, making them part of the solution by giving them responsibility for part of the problem. So, I say when we have communication issues, like MFA is a classic, it’s where we come in and we’re trying to prevent the child from being hurt and not understanding that the child will make mistakes, but it’s part of the learning process for him to understand what his responsibility is to protect himself.
And so we need to think about not how can we most affectively introduce the highest friction to the business to secure the company, but understand how we enable our developers with an acceptable tolerance of risk to double the revenue for the company so we get speed versus security.
[David Spark] Daniel?
[Daniel Krivelevich] I think from my experience… And this is with not just the engineering ecosystem or application security, it’s with every ecosystem. You’re always going to have the person who provisioned a system which is outside the desired policies. And like I said, it only takes one mistake. So, I think our opportunity with security definitely now with AI is to do whatever we can to assume that somebody is going to be negligent or misinformed and identify all the assets, and make sure that we’re covering the low hanging fruits but also that we apply the right controls in the places where they matter the most.
Sponsor – Palo Alto Networks
14:15.412
[David Spark] Before we go on any further, I do want to talk about our sponsor. That’s Palo Alto Networks. So, you know them as a global security leader and a big supporter of our work. They have protected more than 80,000 customers globally, helped them safely embrace Cloud native architectures, and ship secure applications by default.
Prisma Cloud by Palo Alto Networks is the world’s only Cloud native application protection platform on CNAPP to deliver security coverage from code to Cloud. That’s essentially what you want, right? So, they help customers break down the operational silos, which actually we’ve been talking about on the show, between engineering and security teams to accelerate secure application development and build scalable, predictable Cloud workflows.
This is kind of the holy grail. So, with numerous native integrations into developer tooling and powered by the industry leading open source policy as code engine Checkov, Prisma Cloud unites code builders and defenders across a common framework, industry leading threat intelligence provided by Unit 42 and integrated web application and API security capabilities.
They all help protect against immerging and even zero day Cloud threats. As the global security partner of choice, Palo Alto Networks is a recognized leader across more than a dozen industry analysts and third party reports and surveys. So, you know where to find them. You just go to paloaltonetworks.com.
That’s Palo Alto like the city in California and then networks.com to learn more.
It’s time to play, “What’s worse?”
15:58.509
[David Spark] All right, this is a risk management exercise, Daniel. And I always have my cohost answer first, so that would be you, Steve. And this comes from David Ratner, the founder and CEO over at HYAS, who’s also a past sponsor of us. We love them as well.
[Steve Zalewski] Yeah. All right. I’m nervous.
[David Spark] All right, this is a good “what’s worse” because they both stink. I can’t stress this enough, Daniel.
[Steve Zalewski] [Laughs] Geez.
[David Spark] They both stink. You’re not going to go… It’s never one thing so lopsided you’re like, “Well, there’s no way I want that. That sounds wonderful.” Okay, what’s worse, default admin or admin passwords…? So, everything is default admin or the admin passwords. Or your default security is disabled.
So, anything that you have to manually enable that’s all the default security is disabled? Steve, which one is worse here?
[Steve Zalewski] Wow.
[David Spark] They both stink. Both are asking for trouble, right?
[Laughter]
[Steve Zalewski] I’m just thinking, so do I want to get breached in one second or two seconds. Okay, that’s basically what the difference is here.
[David Spark] Yeah, it’s like one will do it in two seconds, one will only happen in one second. [Laughs]
[Steve Zalewski] In one. That’s literally what it comes down to.
[David Spark] That’s your “risk management.” You got that extra second. [Laughs]
[Steve Zalewski] There you go. Okay. And so what do you want to do? Okay. I would say what’s worse is having no security.
[David Spark] So, the default security is disabled. It’s not saying no security. Because a lot of these programs don’t enable security by default, and so all those ones are manual. And so it’s not saying no security across the board. It’s there’s a lot of things that don’t have security enabled by default.
[Steve Zalewski] Okay, so here’s the way I look at “what’s worse” – when the breach happens and I’m called up in front of the CEO as, “Steve, what did you do?” If I don’t have the security enabled, that shows complete zero maturity from a security program. That’ll get me walked out of the door quick.
[David Spark] So, that’s the one second attack.
[Steve Zalewski] If I have default passwords, what I can say is our maturity is low, but we got the security enabled. But it was the next step where we didn’t necessarily have all of the passwords managed correctly. So, it gives me a slightly more defensible reason to show where we were on the maturity curve.
[David Spark] I needed a playing card to break into your house essentially is what I needed.
[Steve Zalewski] That is really stretching to be able to find something good out of either of those “what’s worse.”
[David Spark] Okay. All right. Daniel, do you agree or disagree with Steve here?
[Daniel Krivelevich] So, this is actually a good angle because there is “what’s worse” in terms of what’s better for the CISO to keep his job.
[David Spark] Oh, that’s a good point. [Laughs]
[Daniel Krivelevich] And then also “what’s worse” in terms of what is more beneficial to the attacker. I think in terms of what is better for the CISO, I agree with Steve. But in terms of the attacker’s perspective, if you’re able… And there’s no attacker that doesn’t try the default password. So, if you’re able to log in with a default password, you’re essentially doing whatever you want in the system, having all the data and not only having access to all the data and the operations that the system provides, you’re doing that as a legitimate user, as the admin.
No one can distinguish between you and a regular admin, or it’s much harder. So, it’s essentially like a system having no security. Right? You’re doing whatever you want. Whereas if you don’t have the default password, you somehow have to break into the system. And you can do that maybe because the default settings are not right, but it could also be the case that default settings are good enough and that it’s much harder, and you’ll be detected much easier by SOC or the defenders.
So, I would prefer having it with the default settings.
[David Spark] There you go. So, you want the default settings. You say admin is worse, and Steve says not having the default settings is worse. I got this all right? So, you’re split decision on this. It’s a great answer. Steve, your comments?
[Steve Zalewski] Yeah, I’m just thinking when the script kiddies go wild, and so everybody just runs [Inaudible 00:20:19]
[David Spark] Neither one is good, okay? [Laughs]
[Steve Zalewski] I know, that’s what I mean. Neither one is good. Again, I’m looking into the, “All right, how am I trying to make lemonade out of lemons?” And I’m putting myself in that roll to say, “Okay, we are so naive in security that we just are focused on the functional requirements to build the product and are completely ignorant of security.
Therefore we didn’t turn anything on. We just run everything out of the box because we’re developers.” And part of I think what we’re talking about today is no developer can claim that nonfunctional security requirements are out of scope. And so, again, I’m thinking about the maturity of the industry so to speak and what we’re talking about here.
But ultimately those are two… It’s almost… Well, it’s the first thing in the morning here. And I’m like, “Man, that just has my head going crazy,” because the Ying and the Yang of such difficult choices. Yeah.
[David Spark] It’s not good.
Please enough, no more!
21:26.897
[David Spark] So, today’s topic is application security. I know this is a very large category, but Steve, I’m going to start with you on this. And choose as you like. There’s many angles to take here. But what have you heard enough about with application security, and what would you like to hear a lot more?
[Steve Zalewski] I’m tired of the vendors coming to say, “I’m here to help you.” And what they’re really doing is showing me how to tell the developers that I’m going to look over their shoulder and make them change the way they do things. I think application security now is a little what we’ve been talking about, which is the developers are the business.
And so how are the vendors coming to me and saying, “I want to take and own the problem of giving the developers the responsibility to take the security problem off of my plate as the CISO and make it part of their responsibility.” And so that means we have to think about these security people, process, and tools as targeted for the developer, not targeted for the CISO.
[David Spark] All right. I throw this same one to you. Interesting take. By the way, Steve always take the security issue and makes it clear what does this mean for the business. This is his mojo here.
[Steve Zalewski] [Laughs]
[David Spark] All right? If you don’t know, that’s how Steve operates. So, Daniel, I’ll throw it to you. You live and breathe app security. So, I’m sure there’s a lot of things that frustrate you with the way app security is sold. So, tell me, what have you heard enough about with app security, and what do you want to hear a lot more?
[Daniel Krivelevich] Yeah, so I think the space is undergoing a massive transformation. I think application security used to be synonymous with fast. Application security testing. The domain has been enough for a long while. We have some very well established vendors in the space. But the moment dev ops became a commodity, the moment everything, not just infrastructure, started becoming codified.
The moment CICD became a commodity. That really transformed the problem space and the solution space in application security. And so I think what this means in terms of things we want to hear more of or less of is this siloed approach in the solution space where you have to have a dedicated solution for SAS, and for IAC scanning, and for CICD security, and for containing scanning, and for all these different things.
[David Spark] Yeah, so it’s like you got to figure out the puzzle, how it’s going to go all together. That’s a really good point. We get a lot of frustration with CISOs on that. And especially what you’re describing, essentially the CICD pipeline. It’s a pain in the butt.
[Daniel Krivelevich] Yeah, so I think… I was an app sec practitioner myself, and obviously prior to being in Palo Alto I was an app sec vendor. So, I kind of know the space from many different angles, and I think what people don’t realize is that when you are with a siloed approach, you not only have to rely on yourself to make sure you are aware of all the different risks and all the different categories of risks, and then evaluate all the different vendors in that space, and then onboard them.
Even if you do that, even if you have the best fragmented set of solutions and you have something dedicated for each and every problem, you still have to work on aggregating all of the findings from all the different sources, making sure you have consistent workflows for all these findings. You have to do all the heavy lifting of making your environment secure by yourself.
That essentially… I think Steve talked about this a bit earlier. The responsibility of vendors and solutions is not to make you informed of all the problems you have, is to build a journey for you to solve the problems and help you become more secure.
[David Spark] We get this complaint all the time. Yaron Levi, CISO over at Dolby Laboratories, he made a comment that was a popular post where he said, “I don’t need another vendor to tell me how many more problems of mine they can find. I need vendors to tell me how to solve them.”
[Steve Zalewski] Yeah. So, Daniel, there’s another facet of this I want to get your opinion on which was the definition of a developer ten years ago… If you were developing ten years ago, you knew code. You knew how to be able to build a reasonably large stack. You were actually probably writing code.
And now I would argue the definition of developer has been consumerized. There are people that call themselves developers… For example, like I had this challenge at Levis is I had a whole bunch of people in the business, and their job as developers were simply to make changes to the web pages on levis.com.
And they would do it live in production because they were not true app developers. They were business app developers, and so therefore we have to shift like the thinking about what app dev is and how they operate today to be able to bring additional visibility. But the ability to provide…I hate to say this…protection on the way the business wants to do business.
So, I’m curious for you, have you seen that, and what do we do about that?
[Daniel Krivelevich] Yeah, that’s a good point. the definition of developer is expanding. I think live patching production environments is going away from the world, at least from what I’ve experienced. I think the majority of what organizations can take at the moment is… And that basically is the definition of app sec for me.
App sec represents the transition of organizations going from not having software engineers that write code to having a software engineering ecosystem where app sec is the security umbrella over that engineering ecosystem.
And the role of app sec is securing everything from code to deploy. I think run time is where Cloud security begins, and code to deploy is where the boundaries of app sec are. And, yeah, I know this is open to interpretation. And obviously this doesn’t cover the exact use case that you were talking about.
But, again, the majority of organizations,t he place where they are in their app sec journey is very far from solving that niche use case. I think from my experience, what the majority of organizations are trying to do with their app sec journey is not get from good to great. It’s get from medium to good or maybe even below that.
And for that, going back to the points I made earlier, I think the major milestones for them in that journey is getting that visibility, understanding what they’re protecting, being at an even playing field with the developers, security understanding what the engineering ecosystem looks like under the hood across all the different contexts where code is developed.
There is a category for each problem space. There is SAS, IAC, CICD. So, we need to know what our engineers are doing, and we need to understand what is risky in what they’re doing. And obviously, again, going back to what I said earlier. It’s best if we’re able to do that under one umbrella because if we need to work with a set of siloed solutions, we are in a big problem in relation to priority and assessing risk and becoming more secure.
If you haven’t made this mistake, you’re not in security.
29:34.618
[David Spark] Securing the software supply chains. All right, this also has to do with app security.
[Steve Zalewski] There you go. We got a theme for this show today, David. Holy mackerel.
[David Spark] We got app security all over this. So, in a Substack post, Chris Hughes, CISO of Aquia, argues that because most modern apps are made up of free open source software, you can’t use the same principle with supplies as you would on a manufacturing bill of materials. So, arguing what you just argued, Daniel.
That that doesn’t really apply to the open source. So, actually I’ll start with you, Daniel, here on this. When we’re dealing with a myriad of inconsistently maintained software components, that’d be open source, how can we make sense of securing that software? So, essentially challenging what you just said in the last segment.
[Daniel Krivelevich] Yeah, so Chris makes a good point, and Chris publishes a lot of materials around the significance of SBOM. Basically there is some similarities between the physical world and the physical bill of materials and the software bill of materials thanks to the US government and also many other tectonic plates in the industry.
Organizations are recognizing that when you’re using one package, one open source library, you are introducing everything that comes with it, a full dependency tree of packages. And this is where the software bill of materials become essential, and this is where we need to put a very strong emphasis on understanding all of the dependency trees across all of our code bases to understand what exactly we’re introducing across the full dependency tree, what risks we’re introducing any time we’re using a package.
[David Spark] So, Daniel let me challenge that right now. Because I agree 100%. But saying it and it actually existing are two extremely different things here. So, I think the industry loves the idea of SBOMs. No one said SBOMs stink. But the getting there seems to be the challenge. What do you think it’s going to take to get us there?
And by the way, will SBOMS evolve to something else? Again, I’m throwing it out there. But we agree with it, but it’s such a struggle to do it.
[Daniel Krivelevich] Yeah. To be honest, this is our responsibility or our opportunity as vendors. Log4j changed the industry.
[David Spark] Per your opening comment. That was one of those key moments that changed the industry.
[Daniel Krivelevich] Exactly. Log4j and then Spring4Shell not long after, they are industry defining moments. This is when the term SBOM grew hundreds and hundreds of percents in popularity, and this is where static composition analysis was redefined. And statis composition analysis has been around for many, many years.
It is also a very mature category of solutions, along with SAS. But it is now being transformed because of that, because of what happened with Log4j and Spring4Shell, and some other industry defining moments. And to be honest, I think we’re in a very good direction to make an affective SBOM commodity.
I have some experience building SBOM products by myself, so I know what it requires, and I know the needs of the practitioner pretty well. And I agree, I don’t think we’re in a place that every single organization has a working SBOM which is affective and produces continuously, but I also think we’re not a very big distance from there.
I think at the end of the day, this will become a commodity in the next one or two years. And then the second order problem will be understanding how to sift through all these packages that I’ve identified and find all the CVs there. And how do I from them identify what is actually in use, and what is actually posing a threat to my organization and exploitable by attackers.
That’s the biggest problem after SBOM becomes a commodity.
[David Spark] All right. Okay, I’m going to throw this to you, Steve. Steve, Daniel is so damn optimistic about SBOM. Probably the most optimistic I’ve ever heard anybody. He believes we’re a year or two away, which could…if it works could conceivably solve our third party security issues. Steve, where are you on that?
[Steve Zalewski] I’m going to go, if you haven’t made this mistake, you’re not a true security professional. I would go every security professional, by training, says, “I have to secure the software supply chain.” And I think that’s how we’ve been trained. The mistake now is we’re not here to secure the software supply chain.
We’re here to protect the software supply chain now. Is that we have to move from risk prevention to risk management, and where possible risk reduction. Because what the SBOM is showing us now is where do I have explicit control in the supply chain, which is the code that we actually write versus where is my implicit risk.
Where is the business mandating that the way we write code now is accepting a whole lot of other code into my ecosystem that traditionally I could explicitly manage. So, I say it’s from securing the software supply chain to protecting the supply chain. It’s understanding where I have explicit control over how the developers write code versus the implicit way that we’re now developing the code.
And the SBOM is the shift, left way of me being able to get that visibility to then have a conversation with the developers and with others on, “Well, how do I manage the risk?” So, let’s have that conversation. “And then what can I do to reduce it? And when who owns the residual risk?” So, it really is a risk management conversation now, not a code development conversation.
[David Spark] And it all comes down to that, risk. Because that’s all we’re doing is managing risk. Many have argued we’re not in the business of security, we’re in the business of risk management, right? Everyone should change their titles. Just take out the word security and put in risk.
Closing
36:10.788
[David Spark] With that said, Daniel, that was awesome. Thank you so, so much. And thank you to Palo Alto Networks for bringing on our wonderful guest, Daniel Krivelevich.
[Daniel Krivelevich] Thank you for having me.
[David Spark] I’m going to let you have the very last word. Hold tight though. Thanking again Palo Alto Networks. You know that you can find them at paloaltonetworks.com for as you can see your code two release. Whole pipeline of security issues and also Cloud security issues. But I like how you said the Cloud security starts when it’s all released.
So, thank you very much for Palo Alto Networks. We greatly appreciate your contributions. Remember, go to paloaltonetworks.com. Steve, thank you very much for filling in, being the Marie switching to rock and roll as I mentioned at the beginning of the show. Daniel, any last words? Anything you want to plug for Palo Alto Networks, your application security?
Also, are you hiring?
[Daniel Krivelevich] We are hiring. And we’re building amazing products in app sec, so I look forward to releasing them soon.
[David Spark] Okay. That was great. That was awesome. What a great discussion we had on application security. That was awesome. Thank you so much, audience. We greatly appreciate your contributions and for listening to the CISO Series Podcast.
[Voiceover] That wraps up another episode. If you haven’t subscribed to the podcast, please do. We have lots more shows on our website, ciso-dev.davidspark.dcgws.com. Please join us on Fridays for our live shows – Super Cyber Friday, our virtual meetup, and Cyber Security Headlines Week in Review. This show thrives on your input.
Go to the participate menu on our site for plenty of ways to get involved including recording a question or a comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at david@ciso-dev.davidspark.dcgws.com. Thank you for listening to the CISO Series Podcast.