BREAKING: “Department of No” Upgraded to “Department of Slow” – CISO Series

32 minutes, 59 seconds Read

How can security teams do their jobs without seeming like an impediment to developers? This relationship can seem oppositional. But how can both sides work together to better secure software without seemingly like a road block?

This week’s episode is hosted by me, David Spark (@dspark), producer of CISO Series and Mike Johnson, CISO, Rivian. Joining me is our sponsored guest, Nadav Lotan, product management team leader, Cisco.

Thanks to our sponsor, Panoptica, Cisco’s Cloud Application Security Platform

[embedded content]

Panoptica, Cisco’s Cloud Application Security solution, provides end-to-end lifecycle protection for cloud native application environments. It empowers organizations to safeguard their APIs, serverless functions, containers, and Kubernetes environments. Panoptica ensures comprehensive cloud security, compliance, and monitoring at scale, offering deep visibility, contextual risk assessments, and actionable remediation insights for all your cloud assets.

Full Transcript

[Voiceover] What I love about cyber security. Go!

[Nadav Lotan] So, I love the fact that as engineering groups are heading towards adopting technologies to make better products and better experiences, we, as security teams, must adopt and make sure that we align with them, and support them, and make sure that we don’t put any business risk alongside the technology.

[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 the CISO Series. And joining me as my cohost, you know him, you love him, you can’t get rid of him, his name is Mike Johnson. He is also the CISO over at Rivian. Mike, say hello to the nice audience.

[Mike Johnson] Hello, nice audience. David can’t get rid of me, so I guess yawl are stuck with me, too.

[David Spark] You’re stuck with him. Yes. You know, we’re available at If you want to go back and download and listen to all the archives of Mike Johnson, start at episode one to hear how bad Mike and I were.

[Mike Johnson] Oh, yes.

[David Spark] And then work your way through to listen to us gradually improve over time.


[David Spark] That’s something you do. There are people who have gone back and listen to episodes one through, and I don’t want to hear them again.

[Mike Johnson] I’m happy they do it.

[David Spark] Yes. Our sponsor for today’s episode, a brand new sponsor with the CISO Series, love having them onboard. It is Panoptica, which is…you may not be aware of this…that is Cisco’s cloud application security solution. And they’re responsible for our guest today, who I’ll introduce in a moment.

But first, Mike, I do want to mention that when we’re recording this, CES is going on.

[Mike Johnson] Oh, yes.

[David Spark] And I have attended CES many times. And it dawns on me, you know what CES is? A ton of incredibly cool new products that probably have absolutely no cyber security installed in them.


[Mike Johnson] Yeah, that’s a very good point, that so many of the challenges that we see in cyber security are in devices.

[David Spark] Right.

[Mike Johnson] And CES is all about devices, something new. I saw something about a soft serve ice cream machine that stores the materials… It’s in cans. I want this.

[David Spark] Right. And I’m sure it’s connected, and I’m sure it doesn’t have a shred of any security on it.


[David Spark] And I’m sure the default password is 12345.

[Mike Johnson] I hope it’s like ice cream. I mean, that should be the default password.

[David Spark] You would hope.

[Mike Johnson] Or chocolate.

[David Spark] But, yeah, you never at CES goes, “Look at this really cool new security technology we’ve unveiled that’s with your new television.” You never see that.

[Mike Johnson] No. No. I think that would be quite the differentiator. Hey, next year, folks can make a buzz by focusing on security, and they’ll be the only ones doing it.

[David Spark] [Laughs] And nobody will cover them at all.


[Mike Johnson] David, you’re crushing me.

[David Spark] Well, we cheer on the CES crew and all the new products, and we want them all to succeed.

[Mike Johnson] All of them.

[David Spark] Yes, we want every single one to succeed. Well, I have, by the way… I have seen some… I can’t even remember, but I have seen completely bizarre technologies there. I’m like, “When, how, why?” Because it ain’t cheap to go to CES. And to show off this completely bizarre… Like, do you really think you’re gonna recoup your costs on this?

[Mike Johnson] It’s really weird. Sometimes it seems to be drawing folks into their booth. I heard LG has a camping trailer. LG is never going to make a camping trailer. That’s never going to hit the market.

[David Spark] Yeah, but… No, I understand the point of that is they want to show how their screens would appear if you had a trailer. They’re trying to create… Like a lot of them have these living room setups, and they want you to experience it as if you were in your own living room.

[Mike Johnson] Well, like you said, it’s expensive, and it’s works for a small percentage of them.

[David Spark] Well, I saw LG and Samsung were showing these like see through screens that looked cool. But, again, we’re talking about this now, which everyone is going to hear in March, and it’s going to be old news in March.

[Mike Johnson] Exactly.

[David Spark] You know, they’re like, “What are these idiots talking about? The see through screens have now been surpassed by the see through screens that fly.”

[Mike Johnson] Yeah. We’ll have the failures and successes by the time folks are listening to this, and then they’re all laughing at us.

[David Spark] Let’s get into our show. Enough of this banter. Let’s get into the show. I’m thrilled that we’re bringing on our guest. Very smart guy. If you have interest in application security, you have come to the right place. So, stay where you are. Keep driving. Keep both hands on the wheel if you’re listening to us in your car.

Just keep listening. It is the group product manager over at Cisco, Nadav Lotan, our sponsored guest. Thank you so much for joining us, Nadav.

[Nadav Lotan] Thank you so much for having me, David.

How can we secure new technology without creating new risks?


[David Spark] We have all talked about the need to embrace AI because it’s a business enabler, and it can be a competitive edge. This is no longer a case of using AI for party planning. For many, it’s ready for primetime. 83% of organizations are using AI in production at some capacity, said Shweta Sharma in a CSO Online piece, quoting a Splunk survey.

Now, first, I’m just going to start with you, Mike, on this – where have you seen AI being used as an actual business tool, and what new security issues are you seeing now that’s in primetime that we didn’t see at the onset?

[Mike Johnson] I think it’s still early days. So, there is lots of stops and starts when businesses are testing things out. What I’ve seen from a production perspective is usually chatbots. That’s really the current killer app for generative AI. It’ll change over time as companies figure out more and more what they can do with it.

But a lot of it is enabling the human interface, enabling the ability to talk to a computer as if you’re a human rather than having to talk to the computer as if you’re a computer. And that really is powerful. So, we’ll see some more of that, but I imagine that… I don’t know if it’s 80% of the usage out there is chatbots, but that’s a lot of it.

It is allowing us to see some things that we didn’t first see. One of them was there was some headlines about a car dealership where someone had convinced the chatbot to sell them a vehicle for a dollar, and it was kind of cute and everything. But then someone else came along and realized, “Well, this is just a direct pipeline into ChatGPT.

I can just use this as if I were directly talking with ChatGPT and not having to pay for it.” ChatGPT, like, the full features, costs money. And this business had left it fully wide open, and you could just use the full power of ChatGPT as if you were paying for it. And we saw some of this theft of resources in the early days of cloud computing where…

[David Spark] Yeah, yeah. That’s immediately what I was thinking. Yeah.

[Mike Johnson] Yeah, it’s the same thing.

[David Spark] That seems really low rent though, this theft.

[Mike Johnson] Well, it is, but it’s still theft, and it’s still this company is going to have to pay OpenAI for this usage. So, it’s something that I didn’t predict, and there’s certainly some other things that are going to show up as well over time. But this one was a surprise to me.

[David Spark] All right, I am throwing this now to you, Nadav. Where have you actually seen AI being used as a business tool, and, like, what new security issues did you see…are you seeing now that it’s in production that wasn’t seen at the onset?

[Nadav Lotan] Actually, an interesting group of use cases I’ve seen companies solve who are AI is to actually enhance user experience in security solutions, which is the place we’re interested in. This could be examples from generating code snippets, to secure CI/CD pipeline issues, or other of that sort.

Or even allow users to query complex data sets and complex products using natural languages and actually highly reduce the friction of adopting the security tool and making my environment more secured. From the security [Inaudible 00:08:31] perspective… And I’ll start by following up on Mike’s point.

The risk of actually stealing credentials to use ChatGPT premium, GPT-4, of all those sorts, is not only that I steal the $20 credentials that the monthly subscription costs. The theft is actually infinite amount. I can increase the cloud spend of this organization because they’re paying actually for API goals and for tokens, and not only for the $20 subscription of ChatGPT but rather the usage of the API.

So, on paper, it’s a huge potential theft, as Mike just said. And obviously stealing a few tens of thousands of dollars of car is no less, but I think that the most interesting and most severe use cases of these technologies is when the intersection of the APIs and our back end capabilities, and the entire application stack from my organization’s perspective, this is where we’ll see the most risk come to surface.

And this is what we, as security vendors, must solve for our clients.

How can we align different department’s objectives?


[David Spark] How can a security team address vulnerabilities in projects without resorting to be roadblocks to developers? This question came up in our, the CISO Series… We had a recent cyber security subreddit AMA, and Howard Holton, who’s the CTO over at GigaOm, commented that this comes down to an organizational issue.

The head of the product team has motivation to be on time, not ship secure code. And to address this, Billy Norwood, who’s the CISO over at FFF Enterprises, has seen success in encouraging secure development by framing it as improving time to market, to management, because you won’t have to duplicate work by fixing critical issues after they ship.

Now, that might work to sell the idea to managers, but how do we make sure developers are on board, Nadav?

[Nadav Lotan] Yeah, so I think what security teams usually tend to miss is the fact that shipping fast and shipping product value and security doesn’t have to contradict one another. And I’m saying this both from a security vendor perspective but also from product leadership perspective, which usually might contradict one another.

I think if we boil down how we convince and onboard developers to security, we can narrow it down to three segments. One of them is catching and preventing security findings early in the development lifecycle. No one wants to handle CVEs in production. It’s a big…basically a huge pain, and we need to bring those to visibility really soon.

The second point is to make sure that we educate developers when it needs to happen, not by only opening the Jira ticket for them to fix the issue but also try to educate them on the impact on the environment and the impact on the organization that the new CVE in our environment has brought. This is something that I’ve seen work amazing to get engineering on board with.

And the third one is obviously we need to make sure that we set the guardrails and the policies and whatever we can as security teams to make sure that when engineers will make mistakes…and they will because their lack of expertise and because their lack of tolerance to that domain…we need to make sure that we catch them before they fall actually.

[David Spark] All right. Mike, I throw this question to you. We’ve addressed this many times on this show. What’s your way of getting developers on board?

[Mike Johnson] Yeah, I think one of them… Quite a while ago, we had Kelly Shortridge on the show.

[David Spark] Mm-hmm.

[Mike Johnson] And she recently wrote a book called “Security Chaos Engineering” that I’ve really been enjoying. And it talks about a few things in there. One is the guardrails that Nadav mentioned. And also taking it a step further into not only building the guardrails but building the paved path – the idea of platforms and capabilities that actually make it easier for developers, that make it so that they can build something in the secure way, but it’s actually helping them.

Kelly was talking about a framework that Netflix built called Wall-E. And one of the neat things about it is it allows developers to launch an internet facing app in ten minutes. It just solves so many different problems for them, a lot of which actually aren’t security related. But it also solves the security problems.

So, I really think the key of getting developers on board is to make their lives easier. And Nadav also mentioned finding bugs early that makes the developer’s life easier because they’re in the code at the moment. It’s in their mind. It’s something they can go and address.

[David Spark] I want to take this issue to what happens if the developers don’t do their sort of security due diligence, and an issue happens, and it really points back to bad code. How do the developers feel about essentially being liable for a security issue?

[Mike Johnson] At the end of the day, these are bugs. It’s been a very long time since I’ve been a professional developer, but what it comes down to is bugs don’t feel good. It doesn’t feel great to have a bug – be it a security vulnerability that results in an incident or, I mean, it could be a performance bug that results in an incident.

You could write some code that actually results in the entire site going offline, costing the company directly millions of dollars in a very short period of time.

[David Spark] I just got to imagine it’s demoralizing for a developer, in any case.

[Mike Johnson] So, one of the things that we try and do, especially in the more modern ways of thinking about security, is we do what are called blameless retrospectives. And a lot of that really is to try and make sure that the developer doesn’t just curl in on themselves. Because when they do that, you don’t really get the input or the feedback of what really happened.

So, we actually try and make it so they don’t feel that way, so that we can actually move the entire organization forward. But it’s unfortunately a natural reaction.

[David Spark] Nadav, what have you seen?

[Nadav Lotan] Yeah, I can fully relate to what Mike just mentioned, and there are two parts or two methods of actually inputting a security breach. One of them is, “It’s not my fault, and it’s not my responsibility, but I use the package that contains some CVE, and it’s now in production.” Nothing to do about it to prevent it from a developer perspective, but we should put the guardrails to make sure it does not happen.

The other side is actually when a developer actually inputs a bug, and this actually needs to be treated as an incident and not as a blaming event. We need to make sure that we fix it, and this won’t happen again. And if it will happen then we’ll catch it in time and make sure that it’s handled correctly.

But reduce the politics, and reduce the noise, and just make sure that we solve the issue in the most efficient way.

Sponsor – Panoptica


[David Spark] Before I go on any further, I do want to mention our spectacular sponsor. That’s Panoptica. That is Cisco’s cloud application security solution, provides end to end lifecycle protection for cloud-native application environments. And I know our listeners are in that space, so listen up.

Alright. So, Panoptica empowers organizations to safeguard their APIs, serverless functions, containers, and Kubernetes environments. Panoptica ensures comprehensive cloud security, compliance, and monitoring at scale, offering deep visibility, contextual risk assessments, and actional remediation insights for all your cloud assets.

Powered by graph-based technology, Panoptica’s Attack Path Engine prioritizes and offers dynamic remediation for vulnerable attack vectors, helping security teams quickly identify and remediate potential risks across cloud infrastructures.

A unified cloud-native security platform minimizes gaps from multiple solutions, providing centralized management and reducing non-critical vulnerabilities from fragmented systems. Panoptica utilized advanced attack path analysis, root cause analysis, and dynamic remediation techniques to reveal potential risks from an attacker’s viewpoint.

This approach identifies new and known risks, emphasizing critical attack paths and their potential impact. This insight is unique and difficult to glean from other sources of security telemetry, such as network firewalls. So, get more information on Panoptica’s website. Here’s the web address.

Go check it out.

It’s time to play, “What’s worse?”


[David Spark] Nadav, are you familiar with this game?

[Nadav Lotan] Absolutely.

[David Spark] Two crappy situations. You will not like either one of them, but you have to decide which one is worse. I make Mike answer first. Mike, this one is a little involved, and it’s from a new person who has not submitted in the past. So…

[Mike Johnson] Great.

[David Spark] …very excited to have someone new. It comes from Jaike Hornreich of SDG Corporation, and here are the two scenarios. Scenario number one, you’re locked out of a critical network device, impacting company productivity. Your first call is to the vendor support line, but you quickly learn that you need to update your support plan to access premium troubleshooting.

So, after a couple of hours and additional costs, you finally get connected with an L3 technician who guides you to use an undocumented endpoint with a complex hardcoded password to regain control of the device. Though you’re relieved as operations resume, you can’t shake the feeling, knowing you may be able to access other devices in a very similar way.


[Mike Johnson] Yep.

[David Spark] All right, situation number two. Your team conducts a post incident analysis to understand the scope and implications of the lockout. During the analysis, it is discovered that the same undocumented endpoint and hard coded password were accessed months ago by an IP address originating from another country.

Further investigation reveals that this unauthorized access was part of a more extensive hacking campaign, affecting dozens of businesses including yours. Now though, you find no significant impact from the event to your business, but the shortcut you paid for to regain access to your network was also a zero day.

Which situation is worse?

[Mike Johnson] Unfortunately this exists. Like, hardcoded passwords are a thing.

[David Spark] Mm-hmm.

[Mike Johnson] And it’s amazing to me in the year 2024 that that’s still a situation, so…

[David Spark] It’s kind of mind numbing.

[Mike Johnson] Yes.

[David Spark] Like for example, we had a neighbor who unfortunately had a security issue, and she had told me that she kept all her passwords in a notes document on her phone, and I think, “Oi.” And then I think, “But then again, there’s hardcoded passwords out there.”

[Mike Johnson] Right.

[David Spark] How much different is this?


[Mike Johnson] I think what’s worse of those two is that there are hardcoded passwords out there.

[David Spark] Yes.

[Mike Johnson] But between these two, the way that I see it is in the first scenario there has been no obvious incident. This is not something going on in the wild. It’s not clear that attackers know this hardcoded password.

[David Spark] Right. It’s just you know, “Oh my God, this is an ugly vulnerability that could be everywhere.”

[Mike Johnson] Yeah. I am not happy about this. That then becomes a very different conversation with my vendor.

[David Spark] Yes.

[Mike Johnson] But the second one, it’s very clear that there are adversaries who know this password and are using it. And even though there has not been any current impact, you do your investigation, and you realize, “Okay, they maybe just verified that the thing worked.” They might come back later.

But right now, it seems okay. But at the end of the day, what matters is it’s out there. They’re aware of it. They can use it at any time. And that’s really the worst of these two – is this thing exists, and it is known to at least one attacker out there.

[David Spark] Okay, so what we’re also discussing… This is a what’s worse of two levels of uneasiness.

[Mike Johnson] Yes.

[David Spark] All right, I’m throwing this to you, Nadav. Nadav, you’re ready to answer. Are you agreeing or disagreeing with Mike?

[Nadav Lotan] I fully agree with Mike. I think that the most fearsome part of the second option is the fact that the breach has happened and might happen again, and it’s tangible. We can see it. We can feel it. We can understand the impact on the organization. But to double down on the risk, we might…don’t even know what an attacker did in our system entirely.

So, they might have got access to internal data that doesn’t need to be exposed and find a tricky way to get it out. And by assuming that they have been inside our environment, this is the worst of the two in my opinion. Even though the first one is not good. So, I fully agree with Mike.

[David Spark] All right. I like this. This was an interesting one because usually when we have a, “What’s worse,” scenario, it’s like a definitive. It’s happened.

[Mike Johnson] Right.

[David Spark] But this is just more of a level of uneasiness.

[Mike Johnson] On the flip side, you still might have to disclose that there was an incident. You have to make that decision. And the way that that gets written is we have no evidence that customer data was impacted, and that is very uneasy feeling both to say and to also hear.

Please, enough! No, more!


[David Spark] Today’s topic is value of the platform play. I’m actually thrilled that we’re having this conversation because, oh my God, this conversation comes up again, and again, and again. And I think it’s evolved. So, the traditional argument we’ve heard about the platform play is you choose a platform of tools over best of breed, has been the situation of integration…that you’re going to get a better situation of integration when you have a platform play.

But recently, I’ve heard many CISOs say that it’s actually a cost issue around training. They can’t afford to train their teams across so many tools. So, Mike, what have you heard enough about with the value of the platform play outside of what I just said, and what would you like to hear a lot more?

[Mike Johnson] I’ve been reflecting a lot on this recently. I think you just said it very well, of it’s evolved. A lot of our ways of thinking about platform providers are the old days where they were good at nothing, and you would go and spend a whole lot of money, and you really got nothing other than the fact that you were only writing one check.

[David Spark] That is a good point in that I think the platform play years ago was really… It was truly subpar versus best of breed. It wasn’t platform versus best of… And I don’t think that’s the case anymore.

[Mike Johnson] Exactly. I think it’s gotten a lot better. And so what I really want to hear…what I think we hear too much of is just dismissing the platform play. Just assuming that it’s bad. And I think we should change our perspectives on that. That brings me to what I would like to hear more of, is one of the big advantages of a platform provider is you have relationship with one vendor, and you’re really able to work that partnership.

[David Spark] That is a good point.

[Mike Johnson] Just imagine trying to maintain that across three, four, five vendors.

[David Spark] That’s a juggling trick.

[Mike Johnson] You can’t do it. You will not have as good of a relationship. So, I’d really like to hear more about taking advantage of that partnership you can get with the platform play.

[David Spark] I didn’t think about the relationship angle. All right. I’m going to throw this to you, Nadav. And no surprise, Cisco is totally a platform play here. But it is a more extensive story than we’ve heard before. So, Nadav, I want to hear… Start with what have you heard enough about with the platform play, and what would you like to hear a lot more?

[Nadav Lotan] Yeah, so I’ve definitely heard enough about the fact that it cannot be that platform can do a better job than a best of breed solution. I tend to disagree because platforms today have to keep up with the best of breed solutions and make sure that…

[David Spark] They often buy the best of breeds, too. I should also mention that. [Laughs]

[Nadav Lotan] Yeah. Yeah, this was my next point. That, yeah, if a best of breed is actually defeating a platform in the market, you’ll presumably see an acquisition or a very tightly coupled integration to make sure that the platform can deliver the value of the best of breed solution in one way or another.

And by getting a platform, you actually get the, as you said before, David…the integration, which can create much richer use cases of noise reduction and visibility, which creates far more value from my perspective. So, this is what I heard enough of. The thing that I want to hear more is that platforms are playing some sort of an [Inaudible 00:26:11] approach.

We’ve seen this in other domains. We can look at the…on the observability space where tools are opening themselves to integration to third party services and not only to siloed solution inside the platform. So, this is where a lot of value gets created. [Inaudible 00:26:31] startup ecosystem of creating new capabilities, but you also allow them to integrate into the platform to get leads, to get visibility into one single pane of glass, as we call that.

But you also need to make sure that as a platform you are the one to consolidate all findings, and you’re responsible for the noise reduction and to make sure that the security persona can have at least one dashboard that he consumes the data from. Even though it might contain data sources from multiple solutions.

[David Spark] From your customers, what have you heard customers say to you… He goes, “Now that we’re using this platform, we’re not doing this,” or, “We can now do that,” or, “This headache is gone.” Like, what have you heard from them?

[Nadav Lotan] So, it’s mostly around prioritization. Visibility they have by using multiple tools or our solution. But when you have a way of looking at security from a one, single person perspective, you get to a point when you can ignore all the noise, ignore the thousands, or tens, or hundreds of thousand security incident issues that you have in all of your stack and focus on the few things that matter most.

So, if I’m a security persona that starts my day, and I open my product or another vendor’s product, I need to be able to in a few seconds understand what are my top critical missions for today and handle these. And this is something that we heard from customers that is just changing the way they handle security.

Attention CISOs, your expert opinion is needed.


[David Spark] We’ve talked about the need to update policies to better account for the new LLM-based tools, but what about using those tools to actually write the policies themselves? I’ve heard many CISOs do this. So, Alex Haynes, who’s the CISO at IBS Software, said in a Dark Reading

 piece that he found Google Bard to be affective for updating and making his existing policies more readable.

Mike, have you used AI tools to write policies? And if so, what’s an affective use, and do you see any pitfalls with this seemingly more efficient process?

[Mike Johnson] So, I do think generative is great at summarizing. You can give it a large block of text, pages long, and say, “Hey, what is this really saying?” And so summarization is something that they’re really good at. I have fed our policies into generative AI to just kind of get a feel for what does the summarization look like.

I don’t know that using it to write policies is particularly interesting though. Essentially what you’re doing is copying and pasting from public repositories. It’s not really giving you anything of real value at that point.

[David Spark] But doesn’t that get you sort of a good running start?

[Mike Johnson] But so does copying and pasting from some public repository of policies. It’s no real different. At the end of the day, what generative AI is doing there is summarizing from all of the publicly posted policies. That’s what it’s doing.

[David Spark] Right. Right. But, again, that is… Look, there’s a hundred policies out there. Go out and find them. Summarize them. And it does it for you in seconds, so it is kind of getting you a running start because you would have to do that manually.

[Mike Johnson] I don’t know that it saves you a whole lot. I mean…

[David Spark] I’m arguing pro-AI here.

[Mike Johnson] I think there is actually something AI can do better with regards to policies though. What I really think is interesting is comparing the policies with your controls. What are the actual technical controls that you’ve put in place? Have generative AI look at that and generate the policies set from there.

That then really aligns with your policies as they’re actually implemented versus what I think what a lot of folks end up with is aspirational policies. A generative AI policy can say, “Our passwords are 32 characters long, and can’t have any repeating characters, and must be changed every day.” Nobody is ever going to implement that.

I think it’s more interesting to go the other way, which is what are your practices, what are your technical controls, and turn those into human policy, things that humans can actually read and understand. That’s more interesting to me.

[David Spark] All right, Nadav. I saw a lot of nodding of your head. Do you agree with a lot of Mike’s take on this? What’s your take, and have you done any sort of use of AI to write policies?

[Nadav Lotan] Yeah, so I’ll give a different perspective to the same coin. Basically if you as a CISO write unreadable policies and making sure that nobody in the organization is able to read along, follow along, and fully understand what is required of them, either your employees will discard the policy at hand, or they will use ChatGPT of some sorts to translate your unreadable policies to actually understand what they need to do.

So, it’s table stakes now to make super readable policies and content. And I fully believe that AI will…is already doing a good job at it but also will evolve it to doing a great job. And to maybe add on Mike’s point, I think that we need to make sure that the policies actually are written in a very verbose way but also compliant with what we have set in place to actually enforce them – by using the combination of written policies and actual controls in the organization, and in our environment, and in the day to day of the people in the organization.

This is where generative AI can make sure that we are on par with what we actually set in place. So, I fully agree with Mike’s point.

[David Spark] Regarding, “These are the controls I have. Build a policy around these controls.”

[Nadav Lotan] Yeah. And actually make sure that they are enforced and actually… And the other way around. Like, “These are the controls. Please make sure that I have a well written document.” So, even if someone is not using the controls on the day to day, he can fully understand what is demanded of him.

And it creates some sort of like a single source of truth. I need to update only one of them, and then I can use gen AI to make sure that it is reflected to the written docs and to the actual controls.

[David Spark] Awesome. Well, that’s your advice the next time you want to use AI to write your policies. Don’t just ask an open ended question. Ask it to write it against your specific controls for your specific environment. Good advice from both Nadav and Mike.



[David Spark] Well, that brings us to the very end of this show. I want to thank our sponsor first. That’s Nadav’s company. That’s Cisco. Panoptica, specifically, Cisco cloud application security. Thank you so much for sponsoring. Check out how they can help in that very vein and also with your platform play.

Go to Check them out. All right. Nadav, I’ll let you have the very final word. But first, Mike, any last thoughts?

[Mike Johnson] Nadav, thank you for joining us. I really enjoyed the conversation. Your perspectives, coming from a…as your role of group product manager… It’s great to get the different viewpoints in the show, so thank you for sharing your experiences and your backgrounds. One of the things I wanted to highlight specifically was we were talking about bugs, and you had mentioned the introduction of a bug by a developer using a vulnerable package.

And I think it was really good insight that that’s not really the developer’s fault, but that’s something that we, as security teams, should help protect against. We should make sure that the impact of that is not going to be hard on the company. So, I think there was just a really good nuance there that I don’t think we think enough about, that we really do need to help the developers.

So, thank you for that perspective. Thank you for coming on the show. I really enjoyed the conversation.

[Nadav Lotan] Thank you very much for having me. I highly enjoyed the conversation pas well. I wanted to maybe reflect on the part that security incidents will happen, and we need to either address them before they hit production and before they make like a radius blast. But if they do, we need to make sure that it is handled in the most efficient way.

We fix it fast, and we make sure that we draw conclusions to prevent it from happening the next time.

[David Spark] All right. Anything you want to say about Panoptica to our audience, Nadav?

[Nadav Lotan] Basically, go to the website. Check the product out. Don’t hesitate to reach out for questions either to me or anyone from our team. I’m happy to elaborate on any use cases. We have a lot of interesting solutions in place now and a lot of interesting things that we’re working on that will be announced pretty soon, so stay tuned.

[David Spark] And, Nadav, I’m assuming they can connect with you on LinkedIn. We’ll link to your profile on the blog post. Excellent. Well, thank you very much, Nadav. Thank you very much, Mike. Thank you very much, Panoptica, and Cisco, and thank you very much to our 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, 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 [email protected]. Thank you for listening to the CISO Series Podcast.

This post was originally published on the 3rd party site mentioned in the title of this this site

Similar Posts