It seems like we can’t go a week without hearing reports of a data leak caused by a failure in API security. There’s nothing easy about securing APIs, but it’s hardly the only aspect of security dealing with authentication, encryption, monitoring, versioning, and validation. So why do organizations struggle with API security? 

This week’s episode is hosted by me, David Spark (@dspark), producer of CISO Series and Andy Ellis (@csoandy), operating partner, YL Ventures. Joining us is our sponsored guest, Yoav Nathaniel, co-founder and CEO, Silk Security.

Got feedback? Join the conversation on LinkedIn.

Huge thanks to our sponsor, Silk Security

Full Transcript

[Voiceover] What’s a great approach from a security vendor?

[Yoav Nathaniel] I think the best security vendors lead with transparency and integrity. They’re there to provide value and partner with the customer. They don’t try to oversell and don’t feed them with marketing fluff. They actually do what they say they do.

[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. You know, you can find us at ciso-dev.davidspark.dcgws.com, where we have tons of wonderful programming. My cohost for this very episode, it’s Andy Ellis. You also know him as the operating partner over at YL Ventures.

Andy, say hello to the audience.

[Andy Ellis] Hello to the audience.

[David Spark] Our sponsor for today’s episode is Silk Security, a spanking new sponsor. Thrilled to have Silk Security on board. Remember, revolutionize your risk resolution process. More on that later in the show. But they’re also responsible for bringing our guest. Now, Andy, I was going to mention we were going to talk about something else during the top of the show, but I realize I’m bringing up something else.

I’m calling an audible here.

[Andy Ellis] Excellent. I like audibles. It’s football season. Or it was football season.

[David Spark] It was football season. Although, hold on, don’t we have a new league now? It could be going on now. Doesn’t the other league start now?

[Andy Ellis] Well, yeah, the Women’s Football Alliance League will be starting shortly.

[David Spark] No, there was this other league that I’m seeing advertisements for.

[Andy Ellis] The Arena Football League or something like that.

[David Spark] It could be, yeah. By the way, have you seen Canadian football before?

[Andy Ellis] Yes.

[David Spark] I’ve gone where you only have three downs instead of four downs.

[Andy Ellis] Yeah, and you risk running into the goal posts.

[David Spark] Yes, that, too. I’ve been amused by that. I went to go see it, and I remember just asking a lot of questions. And I remember at the very end, we were… I was seeing it in Vancouver, and they were… It looked like they were going to clearly win unless they did a massive screwup, and I said to the guys next to me… I go, “Could they screw this up?” And they go, “Yeah, they could do it.” And then they screwed it up.

[Laughs]

[Andy Ellis] Yeah. It’s Vancouver.

[David Spark] All right, but that’s not what I wanted to talk about. This show and another one of our shows, Cyber Security Headlines, got a very nice plug on CISO Online where they ask other security leaders, “What are your favorite podcasts?” And they had a list of 12 of them, and 2 of ours, this one included, got mentioned.

And what I loved about it is that CISO Online just…it looked like they clearly just asked people, “What do you think?” And they came back with wonderful quotes from our audience, so I have to just thank them. It was awesome.

[Andy Ellis] It’s awesome. But I do have to say, only 2 of ours made the top 12, so I’m not pointing fingers at the other podcasts, but you clearly have some work to do.

[David Spark] Well, one of the… First of all, one of the shows is not a podcast. That’s the Super Cyber Friday. And the other one is Defense in Depth. Then we do have Capture the CISO, but it’s not frequent. It’s very infrequent.

[Andy Ellis] Yeah, I know. I’m just going to make fun of the Defense in Depth team.

[David Spark] So, it’s really Defense in Depth. But Defense in Depth is doing great. It’s doing awesome.

[Andy Ellis] They’re doing great. They do fantastic work over there. But they were not one of the CISO top 12.

[David Spark] They’re top 12 in my book.

[Andy Ellis] Oh, they’re top three in my book.

[David Spark] There you go.

[Andy Ellis] But not top one, because that would be the CISO Series Podcast.

[David Spark] Enough patting ourselves on the back. Let’s bring our guest on. Thrilled to have them on. Brand new sponsor, and we’re going to have a great, great conversation today, as we always do on this show. Our sponsored guest, it’s the CEO of Silk Security. They were going to bring us the guy who runs the mailroom, and we said, “No, we want the CEO.” And they go, “Okay, we can do that.”

[Andy Ellis] Who also is the guy who runs the mailroom.

[David Spark] Who also runs the mailroom as well. He wears many hats. It is Yoav Nathaniel. Yoav, thank you so much for joining us.

[Yoav Nathaniel] Thank you for having me. Appreciate the opportunity to be here. And having watched the show back when I was a security practitioner myself, I’m glad to be here even more.

Unexpected outcomes or failures?

3:55.958

[David Spark] Are software bill of materials the panacea that will stop the rash of software supply chain attacks? SBOMs, as they’re more commonly known, hold the potential to offer transparency to let organizations better understand underlying software risk. But they are rife with problems, like no consensus on a general format, inconsistent quality, and no reliable way to track vulnerabilities, as pointed out by Kyle Kelly in a recent blog post.

We all want the visibility promised by SBOMs, but what can we do as an industry to make them actually actionable, Andy?

[Andy Ellis] Well, I might have written an op-ed on this about a year ago, which I think is still appropriate.

[David Spark] Okay.

[Andy Ellis] Entitled “Drop the SBOMs,” which hopefully we’ll also have here, but you can always just easily Google it. And the challenge of an SBOM is this, is that people like to talk about it like it’s a nutrition label. Like, “Here’s the ingredients.” So, you know which ones are [Inaudible 00:04:59] right?

And that is the worst possible analogy because on a nutritional label you get to say like “sugar.” You don’t have to say “glucose Monsanto version XYZ.” And somebody now needs to know which one… No, there’s just sugar here. It’s like saying something has TLS in it. Well, is it S to N? Is it open SSL?

Is it some other library? Which version is it? What configuration does it have?”

So, there’s a lot of details that you wouldn’t even get even as you’re getting a bunch of details. But more importantly, where is that software actually being used? Imagine if you went to a restaurant, and they said, “Look, here’s the SBOM equivalent,” the F bomb, the food bill of materials, “of every material used in the production of this food.” And right on the list is Clorox.

You’re going to be like, “Don’t give me bleach. I don’t want bleach.” They’re like, “Oh, but that’s used to clean the floor of the kitchen in which we cook the food.”

That’s the challenge of SBOMs in complex systems is it’s not just the software that you’re using. It’s all of the software in the chain and how do you know what’s usable. So, for me, the people who need to consume SBOMs are people who package software. If I am deploying some form of software, and I am taking something from you and adding it to what I deploy, whether I am doing it as a service or as a package, yes, I need to absolutely know exactly what’s in that software that I am deploying.

But I worry that people have sold SBOMs as being useful outside of that, and I really, really don’t think they are. And I think from a third-party risk management, I think they’re dangerously distracting.

[David Spark] Aw, okay. So, this is only for people with packaged software. Third-party risk management, it actually is far too confusing. Yoav, what do you say to that?

[Yoav Nathaniel] I couldn’t agree more. I think in the modern age, organizations don’t even have a good group on their own SBOMs, and so how are they going to send that to a third party for verification or auditability purposes. We got to solve the first problem first.

[David Spark] Okay, so here’s my question – you brought up what is obviously the problem here. Because if they don’t really know what they’ve got, how do they hand it off. It’s like the worst game of telephone ever. Because it’s like I’m whispering in your ear, fully knowing that what I’m telling you is not the thing that came into my ear.

And so it’s just… It’s not one of these telephone games that goes two to three levels down and becomes a mess. From the first level, it’s already a mess.

[Yoav Nathaniel] That is correct.

[Andy Ellis] Because in that first level, it actually is 20 levels.

[David Spark] Yeah.

[Andy Ellis] You’re talking to an organization that is made up of suborganizations, even if they had a good grip on their SBOM. Let’s just imagine they knew every piece of software they were using and every version. The moment they tried to share it without an architecture diagram of where it’s all used, it’s now worthless.

[David Spark] So, what’s the better use of SBOM, Yoav?

[Yoav Nathaniel] Yeah, organizations that want to have better control over their own SBOMs need to come to understand that not all SBOMs are created equal. It really depends on where you’re creating them out of. So, if you’re doing it out of a repository, in the CI/CD, in run time, through an external scan, you’re going to pick up on different levels of software.

And at run time, you’d typically expect to see the most because you’d see the packaged software, and you’d see the operating system with the preinstalled and any other custom changes that were made. And so by having an understanding of the different versions of the SBOM throughout the software development life cycle, being able to perform a dif [Phonetic 00:08:30] to understand, “Hey, this package came in at this point into my tech stack,” allows you to trace back the origins of any single piece of software.

Let’s look under the hood.

8:41.622

[David Spark] Why does it seem like securing APIs is so hard? By the way, I have written about this, and the answer is, yes, it is so hard. Is it just a matter of complexity? Sure, there is a lot to consider with API security, but it’s hardly the only attack surface that has to deal with things like automation, encryption, monitoring, versioning, and validation.

So, Ross Moore of IT Security Guru points out that many organization simply lack an overall strategy for securing APIs, making managing that complexity a much more scattered shot approach. So, Yoav, I start with you. What is it that prevents organizations from giving API security this more holistic view, which seems critical?

[Yoav Nathaniel] I think the distributed workforce and the distribution of tech stacks. So, everybody uses different programming language, different libraries. If you’re able to embed the workflows and the technology stack and enforce API security through that as a large enterprise, I think you’d have a better control over you’re a PI security.

But in a distributed workforce with many engineers that each one of them wants to do it their own way, it’s just hard to enforce certain practices unless you’re strategically doing it correctly.

[David Spark] Oh, and then that’s why the critical need for the holistic view, and essentially, I guess, sort of one overseeing manager, yes?

[Yoav Nathaniel] Yes, that is correct. If you could make sure that all of your applications and their primary interface, which is their APIs, are done correctly across the board, you’d be able to close a huge gap in your application security.

[David Spark] Okay. Andy, you were laughing at my question. Why were you laughing at my question?

[Andy Ellis] One manager. Look, the two single biggest problems of APIs is a lack of version control and a resistance to deprecating old versions. Boom, that’s the core of your problem, which is APIs have usually but not always…but usually a piece of software or, God forbid, a piece of firmware on the other end of them that are talking to you.

So, when you want to make a change, it’s not like saying, “Oh, I’m going to change the UI on my web interface, and the human can immediately adapt.” No, there’s a computer at the other end that you also have to change the software. And too often, people don’t start with a versioning mechanism where they say, “Oh, I’m going to shift to version two of my API.

Obviously I’ll support version one and version two. And my API has a way for somebody tot ell me what versions they support.”

So, you need to start with that in your API so that you can think about how to work upwards. But so many of these problems… Like authentication for machine identities is brutally hard because you don’t have a human that can do all the little fiddly bits if you need to. And if you don’t think through those and how you’re going to move forward, and then at some point you have to be willing to say, “We’re getting rid of version one.” I remember when I was at Akamai when the TLS wars happened.

When it was like everything week it seemed like there was a new vulnerability in a protocol, and so we’re moving forward. At some point we were still supporting SSL version 2. I will not tell you for whom. But it because they had a gaming console that had a web browser, and it only supported SSL version 2.

And we went… We did the analysis, and there were some number of households of America where the only traffic we saw on the internet was from these gaming consoles, and people were web surfing on them. And really hard and painful conversations about, “At some point, we’re going to stop supporting SSL version 2.” We were the last people to do it.

And when we stopped doing it, these gaming consoles would no longer have a functional web browser. And that meant these houses…that that was the only computing device in the house. Very weird to me, but apparently this was the case. They would have to upgrade in some way. Likely there were low income.

Hard conversation to have about the impacts you might have by turning off an old version of your API.

[David Spark] By the way, that’s a good thing to bring up because this comes up again and again in all levels of different technologies when stuff gets turned off. But if you’re advancing… Sometimes you got to let your, I guess, certain customers go if you’re going to improve the system for everybody.

[Andy Ellis] Yeah. The greatest thing Apple did was with the iPhone. Basically their original API for software updates was awful. And the only way to get to a world where we have what we have now with these automatically updating phones was for them to basically say, “Hi, if you bought the iPhone 1 there will be a day after which it will just not be supported.

Go get a new one.”

[David Spark] I believe I have a first generation iPad that does not… What it is is you can turn it on, but none of the apps…

[Andy Ellis] None of the apps work anymore. Yeah, because they stopped supporting it.

[David Spark] So, Yoav, planned obsolescence is kind of critical here if you’re going to build the business.

[Yoav Nathaniel] Yeah, software and hardware both, they move fast in our world. And you need to make sure that you’re constantly upgrading, updating. And maintenance of technology is increasingly becoming more and more automated, but there is still a lot of human involvement. It’s critical for us to ensure that we’re always up to date with the latest security.

[David Spark] And I’m going to say something that may not be too politically correct, but you are going to step on toes. But you’re going to step on the toes of people who are not going to be your sort of most aggressive customers, I guess, the people who are holding onto the oldest generations.

[Andy Ellis] Sometimes those are your aggressive customers though.

[David Spark] Really?

[Andy Ellis] Think about the… We talked about SBOMs, and there is an aggressive community in the SBOM evangelism side that they want SBOMs so they can do self-support. That’s what they really want is to say, “When the vendor stops supporting this, we would like to have enough information to keep supporting it ourselves because we don’t want planned obsolescence.”

[Yoav Nathaniel] You’re absolutely right, but it’s only applicable to certain technologies that you can build in house. If you don’t buy into the planned obsolescence, you’re bound to have to won your entire tech stack, and best of luck. It could work for you.

Sponsor – Silk Security

14:58.678

[David Spark] Before I go on any further, I do want to tell you about our awesome, brand new sponsor, and that’s Silk Security. Now, are you feeling anxious about risks lurking in your alert backlogs? Frustrated with remediation requests stuck in the twilight zone? Instead of toiling over spreadsheets and watching alert backups build up, Silk helps security teams regain control over their risk posture.

Aw. So, designed with security practitioner in mind, Silk consolidates and contextualizes all of your vulnerabilities, misconfigurations, and AppSec findings across your IT footprint and assets so you can quickly focus on the most urgent risk to your environment and business. Now, Silk then automates assigning the right remediation recommendation to the right owner through the right workflow tool.

Using AI and environmental analysis,

Silk’s predictive ownership assignment eliminates the time suck of back and forth emailing to identify asset and remediation owners. Nobody needs that, right? So, with Silk’s centralized reporting and ticketing integrations, there is no more logging into multiple systems to create a ticket for asset owners and track down remediation or exception requests status.

Security teams get visibility in one place across all remediation tasks by team, by remediation category, and can easily communicate with stakeholders through a single dashboard to provide guidance or keep track of exception requests. Security teams get to both resolve more critical cyber risks in a fraction of time with Silk and shift organizational dynamics through a comprehensive remediation life cycle for better accountability and transparency.

Sounds like a full suite here on remediation and risk management. It sounds awesome. Go to their website, silk.security.

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

16:57.356

[David Spark] All right, Yoav, since you are a past listener, you know how this game is played. Two horrible scenarios. And in fact, I’m going to say these are two truly horrible scenarios. But you get to pick which one is worse, and I will make Andy answer first. This comes from someone who’s never submitted one before, so thrilled to have them.

And I had to have him phonetically explain how to pronounce his name, because it is an Icelandic name. Yeah. So, it is Ymir Vigfusson of Keystrike. Here are his two scenarios. What’s worse for a CISO? A very successful, shivers down your spine ransomware attack against your company on your watch that penetrates everything you had hoped would hold.

Pretty much that’s bad, right? Or an auditor uncovering massive multiproduct misconduct. This is like we’re saying like lying to the SCC or some other big tabloidy scandal, and that is among your most important allies in the company. Which one is worse?

[Andy Ellis] Oh, the second one. No question or me. Because the misconduct. There is the… Yes, you’re going to have an awful day. I actually really, really like this one. Ransomware beats you, beats your security. You had a reasonable security. This isn’t like a, “Oh, you got bit by ransomware because you had nothing at all.” Like you tried.

You tried to implement a zero trust architecture, whatever it is. You got bit. You’re going to have an awful day. Your company is going to have an awful day. Or it turns out you’ve been lying to the government and committing crimes about what you’ve been doing either individually or as a corporation.

Yeah, I’m going to take that second one is worse.

[David Spark] Okay. Okay, so yeah, you put it that way, but I’m going to argue back on this one.

[Andy Ellis] Yeah.

[David Spark] But the second one doesn’t say that you’ve ruined the business. The business can be ruined in the first one, but the second one is, “Wow, you’re really an unethical company, but you’re still in business.” And we’ve seen this happen before.

[Andy Ellis] Yeah, but you said as the CISO.

[David Spark] Yeah, as the CISO.

[Andy Ellis] Like which one… And it’s like imagine if you’re the engineering manager at Volkswagen when it turns out you’ve been lying to everyone about diesel fuel, right? For that person, that is the worst possible outcome because you have no integrity left to sell.

[David Spark] Yeah, all right. Yoav, I’m throwing this to you. Do you agree with Andy, or do you disagree with him? And if so, why?

[Yoav Nathaniel] I completely agree with Andy. As a CISO, you’re hired to create a security program and translate the risk to the business. If you’re lying about that then what are you even doing?

[David Spark] Good point. Nobody can see my side? Hey, sure, they lied… By the way, it doesn’t say that you were the one lying. It’s all your friends that were lying.

[Andy Ellis] Right, but you weren’t able to find it. And I assume it’s security related in some fashion.

[David Spark] Yeah.

[Andy Ellis] Right? So, you weren’t able to find it, which means… So, your best argument is, “I was incompetent at my job.”

[David Spark] Well, yeah.

[Laughter]

[David Spark] I don’t know if I’ve ever mentioned this, but I worked for a company where the woman who was running petty cash had a drug problem and was stealing money from the company. Essentially she was duplicating things.

[Andy Ellis] Right.

[David Spark] Now, speaking of not knowing, the CFO didn’t have a clue what was going on, and she had stolen hundreds of thousands of dollars from the company.

[Andy Ellis] Right. This just happened to one of the NFL teams. I forget which one it was, but literally they just discovered that somebody had embezzled like four million dollars from the team, and that’s everybody’s question, is like, “How did this person actually get away with it?” That’s a lot of money to steal.

[David Spark] Yeah, well… But, again, fingers were pointed to the CFO, who just cried in front of the board.

[Andy Ellis] It happened on your watch.

[David Spark] Yeah. All right. So, we’ll take the ransomware versus the unethical stuff. Not saying that you want ransomware.

[Andy Ellis] Of course not.

[David Spark] No.

[Andy Ellis] Good question, because both of these are awful situations. You don’t want to be either one of them.

[David Spark] Exactly. Thank you very much, Amir.

Please, enough. No more.

21:12.832

[David Spark] Today’s topic is security posture management, and I’m going to start with you, Andy, on this. I’m going to ask the classic question – what have you heard enough about with security posture management, and what would you like to hear a lot more?

[Andy Ellis] So, when we talk about security posture management, let’s be really clear that we are talking about hygiene, and I am tired of hearing about like, “Let’s just deal with the one percent that matters.” Yes, there’s a lot of findings that tools will give you that really, really just don’t matter.

Like please stop giving me information findings. But it is not only one percent that matters. It’s more like 60% of them matter. And imagine if I said brush the teeth that matter. You would never teach your child to brush the teeth that matter. You’re like, “No, I need you to brush your teeth. I need you to floss.

I need you to rinse.” These are all critical things, and that’s what I’d like to hear, is how are we getting to the point that maintaining the hygiene and the security hygiene of our systems is a thing we just do because remediation overhead isn’t brutally painful.

[David Spark] You know, I have a friend who’s a dentist who says only floss the teeth you want to keep. It’s his little joke.

[Andy Ellis] I love it. That’s a great one.

[Laughter]

[David Spark] All right, Yoav, I ask you the same question. Start with what have you heard enough about with regards to security posture management, and what would you like to hear a lot more? And I know this is your bailiwick, what you guys do. So, let’s hear it.

[Yoav Nathaniel] Yeah, I think today the word security posture management is too narrowly focused on specific domains of security, and people are trying to do hygiene for cloud security, or application security, or they do it for vulnerability management with just proactive security process, but many times they are siloed.

Security posture management looks at it holistically and says, “Hey, we have all sorts of issues that need to be treated. We can wait for things to really get bad.” So, we talk about taking showers every day. You can wait until you’re really, really dirty, and then you need an emergency bath. Or you can take a shower every single day and make sure that you’re consistently clean.

And so for large organizations, it’s almost like flexing a muscle on a weekly basis. Making sure that risks pop up, and they’re able to tackle those risks regardless if they’re absolute emergencies or not. It’s all about consistently and continuously taking care of risks that are generated by the business.

[David Spark] This is an interesting way you approach it. Because, by the way, we talk about hygiene all the time on this show, and it’s very much sort of the brand of the show is that hygiene is sort of so key. But what I think is very interesting, and I talked about it with, I remember, another CISO is that sometimes these things just take a long time to hook in.

Like you think about getting people to wear seatbelts. That was a multiyear public service effort to get people to wear seatbelts. So, I’m assuming you see this in your work, that things become a multiyear effort. Like maybe there are things that people do with their security posture today, like wearing seatbelts, that only maybe a small percentage used to do in the past.

What are you seeing now, Yoav?

[Yoav Nathaniel] One, we’re seeing just growing urgency for organizations to improve their security posture or to put on more seatbelts. We’re seeing that it really is depending on the organizational culture, and accountability, and their ability to enforce the processes that they actually care about.

So, some organizations are a lot more mature than others. In the banking industry sometimes you’ll see it. Sometimes in tech companies where there’s a lot of accountability for each employee. And so that translates into a lot of risk reduction, and we’re definitely in a journey. It’s going to take about a ten-year journey all in all that we’ve already started those ten years until everybody learns to put on their seatbelts.

[David Spark] Let me ask you that. So, go back to when you started the journey and where you are now. What do you think is the biggest change in security posture?

[Yoav Nathaniel] I think the understanding that there is so many people involved. You have the people who find out about security issues, who are experts in security, and you have the people who are authorized to take action, make decisions about where the posture is going to go. And all of that needs to align with the management’s risk appetite.

And somehow, all of that needs to all come together. And so what we’re seeing is that there needs to be more clarity at all levels of the business. So, every engineer needs to be aligned with what the security team wants and what they’re telling to management at the end of the day. And it sings like a big symphony.

Everybody understands what they need to do, and the right instructions can actually get executed, which doesn’t happen for most organizations. Security for most organizations is still a big pile of Excel spreadsheets that quickly become outdated. So, it’s just not an affective form of communication to translate risk to each persona that needs to understand it.

[David Spark] All right, now I want to give you sort of the floor to explain how Silk Security is handling this issue. So, how do you work with customers?

[Yoav Nathaniel] Yeah, so Silk is based on our own pain points. We were security practitioners ourselves. I used to lead cloud security for Goldman, and one of the issues we had at the time was how do we make sure that all 12,000 engineers are actually taking care of their cloud security risks. And so with Silk, we really wanted to build something that’s plug and play and takes the lessons learned from the initial enterprise success.

And so we integrate into all of your existing security tooling out of the box, into your infrastructure, into your ticketing, collaboration tooling, active directory, and so forth.

And we gather a lot of intelligence, and we use machine learning to organize your security findings, your assets, your context, and your users in a way that makes a lot more sense for you. Suddenly everything is consolidated, normalized, de-duplicated, speaks a universal language. So, if you have Cloud security and you have vulnerability management and application security, you don’t need to manage them in three separate tooling.

Now Silk can actually manage it all in one place. We do it across any type of complexity, so on prem, cloud, IOTs, and so forth. And we affectively translate all those big Excel spreadsheets into bite-size action items that can be spooned into engineers with advanced workflow, so they can… Each engineer can wake up in the morning and actively manage their own risks.

Looking down the security roadmap.

27:40.438

[David Spark] What do we mean when we talk about modern versus traditional security operations? Is it just integrating modern solutions like SOAR tools or maybe jumping on the AI bandwagon? What really defines it is automation, argues Anton Chuvakin of Google’s Cloud Security Podcast, in a recent Medium post.

So, this goes beyond just slapping some new tools or scripts into the SOC, but rather creating an engineering-led feedback loop to eventually “automate yourself out of the SOC job.” That sounds good, but under that rubric, how many organizations have modernized security operations? Andy, is that a reasonable expectation for most organizations, to I’m just going to say modernize?

Like pushing to automation? Which, by the way, I hear this all the time. This is the desire.

[Andy Ellis] Yeah, so I think automation is a piece of it, but key is to not think of security operations just as the SOC or just like a help desk. We have seen a lot of people modernize their help desks by delivering actually really bad outcomes. Because what they’ve said is, “Our goal is automate, to get to ticket closure as fast as possible.” Rather than to automate for good outcomes.

And as you modernize security operations, you have to say, “What are the good outcomes? We want to automate in that direction. Can we free up our analysts to do threat hunting, to find the things, and to defend architectures versus just dealing with tickets, and closing them, and pushing a remediation pipeline that nobody wants to remediate?” So, it’s more than just automation.

It’s really about driving the right outcomes for the business that are not just close issues.

[David Spark] I love that line, automating good outcomes. Because like for example, if you were to give someone the choice, “Would you like to talk to a human or a bot,” how many people would choose a bot? But I remember like one time I requested a fund on like a Lyft car because we had to cancel it for some reason, and they automatically charge you five bucks for the cancellation.

And I quickly said, “No, no…” I gave some legitimate reason. And it was with a bot, and I was totally happy with the outcome. But it was completely with a bot that it happened.

[Andy Ellis] Right, so bots aren’t bad.

[David Spark] Just because I got the outcome I wanted.

[Andy Ellis] Right.

[David Spark] And it was handled well.

[Andy Ellis] Yes.

[David Spark] Yeah. All right. This is a very interesting discussion. Yoav, your take on this?

[Andy Ellis] Yeah, I think we talked about planned obsolescence, and so I think having modern security operations is absolutely essential. You should constantly look to upgrade the way that you are doing things, make sure that you are being efficient about it. Security risks are rising exponentially, and so your efficiency needs to rise exponentially.

And unless your budget rises exponentially, you need to go for an upgrade. Now, we see that security operations and the tooling that have existed in the market the last few years haven’t had an exact match. Meaning there is too much focus on automation and ultra remediation capabilities.

We think that security needs to have a human in the loop. And getting the right authorized human to initiate either a manual or an automated action is actually an easier way for enterprises to actually modernize their security operations. If you provide a SOAR solution that can automatically fix a vulnerability, but how do you get the right engineer to go and acknowledge that, and approve that, and go through that.

So, being able to facilitate risk around the organization and facilitate the conversations, and being able to identify ownership, being able to prioritize with the risk based model and doing it automatically. So, going back to Andy’s point, if you can get the outcomes that you’re looking for then automation is perfect.

You just need to make sure that you’re getting the right automation.

[David Spark] You know, and I like that phrase, facilitating risk. You’re facilitating everything that’s sort of around risk – the remediation, the discussion of it, the understanding of it. And that, ultimately… If you facilitate risk, people feel more comfortable approaching it. Yes?

[Yoav Nathaniel] Absolutely. You’re not accusing them of anything. You’re just saying, “Hey, listen, we have risk in the organization. We see that it’s related to your activity. Can you help us address it?

Closing

32:01.645

[David Spark] Excellent. Well, that brings us to the very end of the show. We hopefully facilitated your listening to this very episode of the CISO Series Podcast. I want to thank Yoav’s company, Silk Security. Remember, their web address is pretty easy to remember. It’s silk.security. How difficult is that to remember?

Not hard at all. Why not go to silk.security and facilitate your risk efforts as well. Thank you very much, Yoav, for sponsoring this episode. I will let you have the very final word on this. Andy, any last thoughts on our conversation today?

[Andy Ellis] I think it’s really important for folks to really always drive to outcomes. I think we touched on that everywhere here – is security needs to be outcome driven. What are you actually trying to get done with your program. This is not doing a program for the sake of a program.

[David Spark] Very good point. And I love how you sort of add that definition of we’re automating better results, just not automating a process, if you will. Yoav, any last thoughts? And by the way, please feel free to make a pitch for Silk Security. Anything that you have not mentioned on the show so far.

[Yoav Nathaniel] I appreciate the audience listening. And if you’re looking to see a better way and a faster way to achieve the results you are looking for when it comes to security remediation, risk reduction, or just better auditability of everything that you’re already doing… Because we talked about auditors earlier in the show.

Come talk to us. We’re always happy to talk.

[David Spark] Excellent. Thank you very much. All right. Well, audience, we greatly appreciate your support as well. Keep them coming. I want more, “What’s worse,” scenarios. Ones that will stump Andy. I thought that one was a good one. But, yeah, honestly when it’s like a be unethical or ethical, they always say being unethical is far worse between the two.

[Andy Ellis] Yeah.

[David Spark] But they were two bad scenarios as well.

[Andy Ellis] In a sense, when they’re really, really bad, it actually makes it liberatingly easy. Because, yes, these are both awful. I accept that I don’t want to be in either one, and so I get to say, “Oh, I’ll take the ethical high road.” Like where you make it like, “Oh, maybe that one wasn’t quite so bad,” then it becomes interesting.

[David Spark] Exactly. All right. Well, thank you again to Silk Security. Remember, silk.security for your risk understanding. Risk facilitating efforts. I love that phrase. Risk facilitation efforts. Go check them out. Thank you. Please, give us more, “What’s worse,” scenarios. Contribute more. We love it.

Tell your friends about us. Go leave a review. I never say that. Go leave a review on your favorite…wherever you listen to your podcasts – on Apple Podcasts or wherever. Please do so others can discover us as well. And thank you 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.