https://cisoseries.com/whats-next-in-cybersecurity-look-at-last-year-and-expect-more/
This week’s episode is hosted by me, David Spark (@dspark), producer of CISO Series and Andy Ellis (@csoandy), operating partner, YL Ventures. Our sponsored guest is Ori Arbel, CTO, CYREBRO.
Full transcript
[Voiceover] 10-second security tip. Go!
[Ori Arbel] After you bought it, that’s awesome, but make sure you set it up properly. In a month or two months’ time, go back, revisit it, make sure that it’s still set up and configured the way you wanted it to be.
[Voiceover] It’s time to begin the CISO Series Podcast.
[David Spark] Welcome to the CISO Security Vendor Relationship Podcast. I’m David Spark, producer of the CISO Series. My cohost joining me for this very episode is Andy Ellis. He’s also known as the operating partner over at YL Ventures. Andy, people like to hear that sound of your voice. What does it sound like?
[Andy Ellis] Let’s see. Today it sounds a little like this. Slightly gravely because I’ve just gotten over COVID.
[David Spark] It doesn’t sound gravely. And by the way, kudos for getting over COVID. We’re available over at CISOseries.com. This show and all our shows, you can find more of it right there. Our sponsor for today’s episode is CYREBRO. And we actually have a special guest from CYREBRO will be with us. I’ll introduce that person in just a second. But first, Andy, I want to go off of what our guest was saying in the opening tease which was if you bought it, set it up, check it – make sure it’s set up. This whole issue of configuration drift. But it’s more than just configuration drift. Is it literally on?
[Andy Ellis] Yeah. Oh, the number of security solutions I’ve encountered in my career that during some incident people were just troubleshooting, so they turned everything off… And it was all the stuff they didn’t like anyway, so all the security stuff gets turned off first. None of it was to blame, but they could turn it off in an incident. But now you have to go back through change management to turn it on once you realize it’s actually off, or been pulled out of line, or whatever. And I think this is probably one of the bigger blind spots in a lot of security teams is we think we have things that work, but they’re not even on.
[David Spark] Good point. And by the way, that’s not just in security. Think about the number of times even doing this show, “Why isn’t the microphone working? It’s not on.” Or, “Why isn’t the phone working on? It’s not turned on.” So many problems can be solved by turning things on.
[Andy Ellis] Oh, yeah. I got onto a call the other day, and I could barely hear people. We’re trying to figure out what’s going on. And I just have an extension for my in-ear monitors. When I’d gotten up to hit the restroom before the call, the connector had pulled out halfway. So, it was connected just enough that I could hear them but not enough that I could make sense of it. And it was probably like four minutes trying to debug what was wrong. And it’s like, “Oh, yeah. This thing just got disconnected.”
[David Spark] I will also throw out… And we experienced this when we did our live show in Rhode Island. Don’t place yourself in a position where you may turn something off in the process of using it where I literally had my foot on the power table and turned off the entire mixer at the very beginning of the show.
[Andy Ellis] I’ve been involved in one worse than that, which was at a Superbowl. The Patriot’s Weekly radio show was going on in the hotel that I was staying in. And so they’re sitting down in the lobby of the hotel. They’ve got everything set up, and they had one chair sitting in front of them. And so I dropped over, and I sat in the chair to listen. It was a lot of fun, especially when there’s caller. You can’t hear the caller, you just hear the studio. But I just wanted to slide the chair back, so I did. Not realizing that the chair was there protecting the outlet that they were plugged into. So, when I slide the chair back, I unplugged them, and the radio show goes dark. Live radio show.
[David Spark] Way to go, Andy. [Laughs]
[Andy Ellis] Killed it. Fortunately they all looked up. I figured it out, plugged it back in. But it’s been a running joke now whenever any of the hosts run into me. They’re like, “Yeah, stay away from my power.”
[David Spark] [Laughs] Well, let us get to our guest today, who we’re thrilled to have him on board. It is our sponsor guest, Ori Arbel. He’s the CTO over at CYREBRO. Ori, thank you so much for joining us.
[Ori Arbel] Pleasure. Happy to be here.
How CISOs are digesting the latest security news.
4:02.065
[David Spark] What are the Cloud security trends of 2022? Who knows? I saw literally dozens of articles with the same exact title – “X Cloud Security Trends of 2022.” And what’s interesting is that everybody’s list was completely different than everybody else’s. It was more a list of what to be concerned about in Cloud cyber security, which by the way that list is extensive. But I thought eWEEK actually had a list that actually looks like trends, and none of them will surprise you because it’s a lot of what already happened in 2021. So, surprise, we’ll probably have more of it in 2022. On the list, supply chain attacks will rise. Cloud breaches will be a fact of life. Cloud maturity will make a difference. Zero Trust picks up speed. Machine identities will be an Achilles heel. All right, when COVID started, those companies that were Cloud native had a leg up on everyone else. For those companies who were not Cloud native, where first would you suggest their Cloud security needs to mature, Andy?
[Andy Ellis] This one is a hard one, and I completely agree with you. Just predict what happened last year is going to happen this year, and you’re probably not far off. It reminds me a long time ago, there was a study of which meteorology departments were the best at forecasting the weather. Cal Tech’s was the best. I forget what the percentage was. Like 83% or something. But they pointed out if they had just predicted that tomorrow would be the same as today they would have been two percent more accurate than they actually were.
[David Spark] [Laughs]
[Andy Ellis] So, you’re like, “Oh, yeah.” Because it’s always sunny and fair in Pasadena. But when I look at the Cloud native, if you’re not Cloud native, what do you need to do is I think you need to understand what is your Cloud strategy. Because at this point if you’re still not even Cloud first, your Cloud is an afterthought, you’re behind. But that gives you an opportunity… You’re not going to lift and shift. You’re not picking up your current infrastructure and moving it into Cloud because Cloud gives you so many tools, either baked in or available as Cloud native application security, that you get to start over. And that’s a huge benefit. So, the first thing you should actually be doing is saying, “What do I want? How do I want to build it in Cloud? And how am I going to do it by taking advantage of everything Cloud provides me under the covers?” I’m not going to try to build something and then tack on Cloud. It really does have to become Cloud first for my next evolution of my technology.
[David Spark] Great advice. Ori, I’m throwing this same question to you. Where first do you think their security needs to mature?
[Ori Arbel] If I have to pick one, I’d probably say understanding the attack surface for the most part. You’re moving onto something new. You shifted from the on prem traditional set up onto a Cloud. Understanding the attack surface, having a whole new realm of operation, that would be the key for me. I see a lot of pain points there. I see a lot of hits. Definitely the first point I would look at.
[David Spark] And so give me a little bit more depth into that – specifically in that what is a Cloud attack surface just look like as opposed to on premise?
[Ori Arbel] Look at it this way – just the fact that you’re in the Cloud and not on your on prem… You’re on the internet so to say, managing your roles and responsibilities, you’re making sure that everything is locked tight is key. Because if you’re moving on and you’re trying to set up, and you want to make sure that everything is communicating the way it should communicate, and everything talks to each other… Lots of times people tend to overly exaggerate when they’re opening things. By that they enlarge their attack surface. Just random things like their S3 buckets are open to the world. They didn’t mange it properly. And then you find in a year’s time that you have buckets with loads of information, not to talk about keys that are in there. But the buckets are open. The attack surfaces change because it’s not on your own on prem anymore. It’s on the internet. So, small things that you used to not care about all of a sudden have a huge difference. They have a huge impact. Simple things like that.
Pay attention. It’s security awareness training time.
8:19.294
[David Spark] What comes first – training or the phishing simulation? Tip of the hat to Jonathan Waldrop of Insight Global for bringing this to my attention. It was a debate initiated by Gabriel Friedlander of Wizer. And there are arguments for both sides here. So, the argument for training is…meaning training first…what’s the point in testing the team if you haven’t actually educated them? And the argument for phishing first or a phishing simulation first – we need a baseline to measure progress. So, lots of discussion on this topic. But training won out in the poll with 61% of the vote. Matt Crouse, the CISO over at Taco Bell, argued, “If you don’t teach before you test, why bother to test at all? Why is my user base going to care if they pass or fail a simulation if I haven’t taught them how to succeed first and why it matters?” I’ll start with you, Ori. Where should you begin in a sort of security awareness effort? Should you be teaching first or testing first?
[Ori Arbel] Definitely testing first. There’s no right or wrong answer, obviously. As you said, it was a debate. But I’m a big believer in understanding what you need to teach. If you don’t test first… And awareness, it’s a big word. There’s lots of areas for awareness. You need to understand where do you need to put your efforts and the training fees. So, you need to test. You need everybody to fail. Yes, everybody would fail. We’re not testing them the first get go. We’re understanding what we need to emphasize on, and where do we need to strengthen our awareness training. So, definitely test first.
[David Spark] This question reminded me. I took Russian history in high school. And I remember on day one, the teacher gave us a quiz on Russian history. It was all to prove us how little we knew about Russian history, and it was scary. Like it was some really basic questions. And so I kind of likened it to… We weren’t upset about it, and we weren’t graded on it. But it just made us all realize, “Oh, gee, we really know nothing here.” And it made us sort of sit up a little bit more. That’s why I was very intrigued by the testing first theory. Andy, where do you stand? Test or train first?
[Andy Ellis] So, I actually think that most phishing tests are completely worthless other than to boost the ego of the security teams. Because we get to say, “Aw, look how stupid everybody else is.”
[David Spark] Or how wise they all are. “Look how well they did. We trained them so beautifully.”
[Andy Ellis] No, because we know that we’re not sending real hard phishes. If somebody really wants to craft a great phish, they’re going to get it through because our email infrastructure sucks. The real problem we have is we have email infrastructure that hides the real sender from you, so anybody gets to say whoever they want to be. We have things that if you click on them, they can own your computer. We have authentication systems that are not multi factor and use portable passwords. The whole problem that we have here is our entire IET control infrastructure is a disaster, and then we blame the users because they click on links like we trained them to. Because you don’t get to get paid if you didn’t click on links, and you don’t have your medical insurance set up if you didn’t click on links. So, there’s all these things they have to do. So, I actually think that the only real purpose of testing is as a training method itself. To train people by testing so they can see, “Oh, that’s what some phishes currently look like.” But the challenge we run into is the real things that people do to attack us are really off limits. Like sending people gift cards is totally something the adversary does. But if you pretend to send somebody a gift card, or a bonus, or whatever, you’re going to be lambasted, as you should.
[David Spark] As… And by the way, GoDaddy got slammed for this. You remember?
[Andy Ellis] I remember. But what GoDaddy was doing… I understand why because they were trying to emulate what an adversary would do.
[David Spark] Correct.
[Andy Ellis] But unfortunately an adversary gets to do things that you don’t get to do to your employees.
It’s time to play, “What’s worse?!”
12:26.278
[David Spark] Ori, you’re familiar with this game, correct?
[Ori Arbel] Yes.
[David Spark] All right, so we’re going to give you two bad situations, and you have to decide which of these two bad situations is worse. And I always make my cohost answer first, so Andy will answer first, and you can agree or disagree with him. I like it when you disagree.
[Andy Ellis] Know that I win if you agree. David wins if you disagree.
[David Spark] There you go. So, you have to decide who you want to win. All right… And by the way, we have the power to edit this show. Just throwing that out there.
[Laughter]
[Andy Ellis] So, you might think that you let me win, but then David will completely edit your words, and I’ll discover I didn’t win.
[David Spark] There you go. All right, this comes from Jamie Leupold, who works for PreVeil. And here is his “what’s worse” scenario. A solution that is very hard for end users to use but requires minimal IT overhead configuration and updating versus a solution that is very easy for end users but requires constant configuration changes, updates, and service aid patches [Phonetic 00:13:34] so difficult who knows if you’ll ever be able to keep up with it. So, Andy, which one is worse?
[Andy Ellis] This is really hard because it depends on how central the user is to the system. I’m going to assume that the user is central to the system. So, it’s not I get to think about just the security tack on where it’s like, “Oh, if I tack security onto a core system I have now made it unusable versus very usable.” And this one is really easy for me because I’m going to go with the worse one is the one that makes it unusable to the users. My logic there is very simple, which is I have to think strategically. If I deploy a system where the users hate me then I will never deploy anything ever again. And so it sabotages my entire security program. Whereas if I deploy something that my users love but is expensive to maintain, at least I have not destroyed the good will of the company. Now, I might have a problem retaining my staff, so a completely different problem to have.
[David Spark] Yes. Again, it’s a what’s worse. They both stink, but it’s…
[Andy Ellis] They both stink, but let’s go with the place that concentrates the stink onto the security and IT organization and makes everybody else happy with us rather than something that, “Oh, we have it really easy, but it’s a disaster for everyone else.”
[David Spark] All right, good answer here. All right, Ori, do you agree or disagree?
[Ori Arbel] Absolutely agree. I come from a cyber security background. Everything is overly complicated in the background. But if the end user is not going to end up using it then what’s the purpose? So, definitely agree.
[David Spark] So, you follow the same belief that Andy has here? That it sucks that my security team is going to have to deal with this, but better than the end users dealing with it?
[Ori Arbel] Oh, yeah. Absolutely. I’ve been doing it for 15 years.
[Laughter]
[Crosstalk 00:15:24]
[Andy Ellis] …like a swan, right? Everything looks graceful above surface, but under water we’re paddling furiously.
[Ori Arbel] Oh, yeah.
[David Spark] Mike Johnson…he says the comment of the ducks. Ducks look peaceful on top, but they’re paddling furiously underwater.
[Andy Ellis] Yeah. I use the swans mostly because they’re also very cranky. And actually my parents user to have a company named Crystal Swan that ran… An inn. And so when you’re an innkeeper, it’s absolutely like that. Everything has to be beautiful and graceful, but behind the scenes there is never a calm moment.
Please, enough! No, more.
15:57.288
[David Spark] Today’s topic is the SOC. And by the way, I can’t believe we actually haven’t done a whole segment on the SOC for this segment yet. But the security operations center. So, let’s give this some good breathing room and some good discussion here. So, I’m just going to ask you the question I always ask in the segment. Andy, when have you heard enough about with regards to SOC, and what would you like to hear a lot more?
[Andy Ellis] I am tired of hearing how hard it is to hire people for your SOC. I’m done with that conversation. Your SOC includes entry level and growth positions, and you should be hiring staff and developing them. That’s my simple one. And if you’re out there going, “Oh, I don’t know how to do it,” I will happily consult with you about how to think about building a great pipeline and bringing staff in and developing them so they stick around. Let’s stop talking about hiring because that’s the easy problem. The hard thing is how do you get tooling that is business friendly that really gives you process automation across the entire life cycle. Because too much SOCs are, “Let’s just throw bodies at panes of glass with alerts that are context free, don’t matter.
We’re going to inundate you with thousands of things.” We had that problem 30 years ago when I was in the air force. This should not be the same problem that we’re repeating. And I think it’s often driven by the vendors are terrified of the false negative. If you’re a vendor and one of your customers get breached, which they will… No vendor is perfect. Even at their core technology, let alone everything. But you want to be able to say, “Oh, well, there was an alert that you should have seen.” Even if it was buried in a million other alerts. You could say, “Ah-ha, here was this alert that if only you had noticed you would not have been breached.” This shift of liability because you’re afraid of saying, “Look. Yeah, no, we don’t give you all of the possible alerts because we want you to focus on things that mostly matter. And sometimes, yeah, that means that we won’t show you a thing that you would have ignored that might have stopped a breach.”
[David Spark] All right, I like that, Andy. Ori, I throw the same question to you. What have you heard enough about with regards to the SOC, and what would you like to hear a lot more?
[Ori Arbel] Buzzwords for the most part. AI, automation, machine learning. Lots of buzzwords. Buzzwords, buzzwords. People say stuff…
[David Spark] Buzzwords essentially to sell the SOC. Like, “Hey, we’ve got machine learning in our SOC, and it’ll find your stuff. And we’ll give you all the alerts and tell you…and give you a single pane of glass, and it’ll be green, red, yellow. You’ll never know whether you’re safe, or you’re not safe.”
[Ori Arbel] Exactly. Absolutely. Buzzwords that are used for marketing for the most part – I’ve had enough of that. What I’m interested in finding out more is how do you actually use those things in the SOC. Because they are important. They are the future. AI, machine learning, automation. This is where we’re going. What I want to hear more about is how do you actually take those things and utilize them, and refine the SOC to the point where there’s value for the consumer at the end.
[David Spark] Let’s actually talk about what you’re doing with CYREBRO, because this is your bread and butter. This is what you do. How is it you’re doing just that?
[Ori Arbel] What we’re trying to do at CYREBRO is we’re trying to look at the traditional SOC being a service. We’re taking that. We’re turning it into a product. We’re looking at it more from a preemptive, proactive solution SOC is no longer a service. It’s a solution. So, essentially it’s becoming a product where we are tying all those things in together. We’re taking automations. We’re taking the machine learning. We’re taking the AI. We’re taking all those buzzwords. We’ve actually got specialists in house that are utilizing it in the workflow in order to maximize and speed up the process of discovery. And what Andy just said – enough of false positives. I’m interested in refining the alerts that are coming. I’m interested in creating crystal clear, to the point, don’t overcomplicate it, what am I looking for, what do I need to do, how do I address it, how do I move on, how do I prevent it from happening again in the future.
[David Spark] So, can you give me an example? Because… By the way, there’s so many SOC tools out there. So, what is the story that you tell that shows how you’re unique as compared to your competitors or a scenario how it plays out using your tool? Can you explain?
[Ori Arbel] Yeah, absolutely. The traditional sense is throwing a whole bunch of logs at the SIM, at the system – having a single event driven detection, which is essentially a high false positive machine. And throwing everything back at the customer or throwing everything back at the end user and saying, “This happened. What do you think? This happened. What do you think?” We’re looking past that. We’re using all those buzzwords, again, that I described before to refine the process, to create an attack story. An attack is no magic pill. It’s a process. It’s built out of steps.
[David Spark] So, you’re connecting the disparate elements that should actually be connected to say, “Hey, we saw…”
[Ori Arbel] Absolutely.
[David Spark] “…it here, here, and here. That tells this story.” So, just give me an example of that.
[Ori Arbel] The classic example is I’m looking at an email. I’m seeing email. We call it impossible travel. I’m seeing users log in from multiple places at the same time. Maybe interesting by itself, maybe not. There’s VPN today. People are traveling. So, I’m looking at it and saying, “Okay, this one is interesting.” Then the next thing I’m seeing is that somebody downloaded a file. Now I’m seeing that this file is starting to propagate. It’s a dropper. It’s starting to propagate. Now the EDR is alerting, “Hey, this machine that the user with the same username had just logged in from multiple countries. Now he’s downloading a file that the EDR Is alerting on.” Now I’m trying to follow this trail and understand, “Okay, there’s an attack factor here. Somebody broke into your email. Somebody had downloaded a file. Somebody is trying to walk in and start crawling in your environment.” So, I’m connecting all those dots fast using machine learning, using automation, using anomaly detection. I’m taking all those things. I can draw a map of what’s happening in real time, and I can start stopping it. I can start addressing the issue of how to mitigate the issue. But I’m looking at it as an attack story and not as a bunch of single events. This is the main focus here.
[David Spark] Andy, any follow up questions from you?
[Andy Ellis] Well, I think there’s this fascinating approach here to say how do you connect and tell a narrative rather than just tell facts. Imagine if you tried to take any fairytale and stripped it down to the facts of what’s in it. And then like you said, “Oh, there’s a character with long hair.” That’s not a narrative that somebody is interested in. So, I like this idea of how do you build the narrative. And sometimes it’s not a chain. I think that would be sort of my one question, which is how do you look at places where there’s not an obvious chain, but there’s a narrative that ties these facts together.
[Ori Arbel] Exactly. That’s also a thing. It’s not necessarily always going to happen on the same device so to speak. Maybe I’m looking at somebody’s email but somebody else’s device. So, it’s not necessarily a single entity-based attack story. It’s exactly like you said. It’s a narrative. I understand, and I know what an attack looks like and the parts that are supposed to happen. And they’re not necessarily happening at the same time. They’re not necessarily happening on the same entity. But I know how an attack looks, and I’m looking all around. And I’m tying it all together. That’s a very good point.
How have you actually pulled this off?
24:02.054
[David Spark] How can you improve your incident response planning? On CISO Online, Susan Bradley offers these five suggested areas for improvement. One, know your cyber insurance carrier’s beach processes. Two, have a communications plan in place. Often we discuss tabletop exercises on this show. Understand the relevant breach notification guidelines and regulations. Have a vulnerability disclosure program in place. And last, consider penetration testing services. So, all of these take time to work on. I agree with them. But, Andy, I’ll start with you. Pick one or two. And what’s your experience on improving on any of these? What are ways to fast track the planning?
[Andy Ellis] Let’s take the communications plan. This is the easiest one to fast track because you can basically outsource it inside your company to your comms team. They really want to own the communications plan. And so you’re going to talk to your PR team, to your corporate communications. They’ll give you a body to drive and coordinate this because they ultimately want to be in charge of it. And now what you’re going to do is you’re not going to use tabletops. You’re going to use live incidents. When I was at OCMI [Phonetic 00:25:18] was easy because we had the same incident program for security incidents and non-security incidents. What you just do is you just declare on an incident… You just say, “We’re going to pretend that we’re going to communicate publicly about this.” And so now you’re going to take…you’re going to run through your plan, and you’re going to create the public communications. And you’re going to do everything.
And at the last minute, you’re going just going to not publish. What’s also nice about that is it gets the company in the mindset of create the communications even before you’ve decided whether you need to communicate. Because often times companies delay, and they’re like, “Well, we don’t know if we need to do a breach notification yet.” And by the time they might figure it out, it’s actually they’ve already passed the SLA for notification. Now it’s easy to convince themselves, “Oh, once we’re already past the SLA, why does it matter if we wait another day for better notifications, better knowledge?” When the reality is communication wants to be fast and furious. Like as soon as you notice there’s an issue, you actually want to communicate,
“Hey, we’re noticing an issue. Maybe it’s nothing.” You’re going to practice that. And so do it with live incidents. Even if you’re never going to communicate them, practice everything in the flow of generating. Make sure legal is involved, marketing, comms, and the tech team.
[David Spark] I love that advice of writing it all down and deciding later if you’re going to publish it rather than deciding whether you’re going to publish it, and then [Inaudible 00:26:36] goes, “Oh my God, we need to write it down.”
[Andy Ellis] Right, yeah. And we would set times. We would say, “This is the time when we will decide if we’re going to publish this variant or not of communication, so we have to have something ready at that point.” And if someone said, “Well, I’ll have data for you in three hours,” it’s like, “Okay, great. Well, we’re going to write a communications and presumes we don’t have the data.” And all of a sudden people would be like, “Oh, I’ll have the data for you in 30 minutes.”
[David Spark] Oh, really?
[Andy Ellis] Sometimes that would happen. They’d be like, “Oh…” They hadn’t realized that we were going to drive everything off of a communications timeline. And so if they wanted to be in that drop, they needed to have their data available.
[David Spark] Ori, I’m throwing this to you. On any of these five items, what way could we greatly improve them? And most importantly, how quickly can you sort of fast track the planning of any of these?
[Ori Arbel] Can I throw a curveball here?
[David Spark] Sure.
[Ori Arbel] Can I suggest a sixth point that I think is crucial?
[David Spark] Sure. You think it’s more important? Go ahead. Let’s hear it.
[Ori Arbel] Absolutely. All those things are very nice, but there’s an initial point that comes before all of these, and that’s roles and responsibilities – who is in charge of what, who is actually going to investigate, who’s going to communicate, who’s taking charge. Most often when we come into an incident response, everybody is all over the place. Everybody is running. Everybody is panicking. The house is on fire.
[David Spark] Well, then I think actually what you’re saying is falling under number two, what Andy was talking about, having a communications plan in place. They just don’t have one.
[Ori Arbel] It’s both. It’s a communication plan in place, but also roles and responsibilities. Communicating is awesome, but who’s in charge of doing what?
[David Spark] The actual doing. It’s not just talking. It’s the actual who’s doing what.
[Ori Arbel] Exactly. Because I’m coming from the seat of somebody who’s actually managed and took part in investigating and conducting a live incident response. People that are just doing tabletops, they’re ready. Everything on this list is ready, and they know their part. When an actual incident is happening, people lose their minds. The house is on fire. People start dropping the ball on one end. The other hand, people are duplicating missions. You find out two hours later that three people are working on the same task, neglecting something else that’s very important. So, actually understanding who is in charge of actually hands on doing something is crucial. Because if you don’t have that, anything else goes away.
[David Spark] I think that also is a nice book end to your opening tip of the show, what you were saying, when you buy it, make sure you turned it on, and you configured it. And then similarly you hired these people. Make sure they’re doing the thing they think they should be doing, and we all know what everyone is doing.
Closing
29:23.802
[David Spark] Perfect way to close our show. Excellent, Ori. I appreciate it. That was Ori Arbel. He’s the CTO over at our sponsor, CYREBRO, and also was Andy Ellis. Now, CYREBRO is our sponsor. I’m going to have you say the last word here, so please make a pitch for CYREBRO, any offer you have for our audience. And the question I ask all our guests is are you hiring. Please have an answer for that. But first, Andy, what’s going on? Any last thoughts?
[Andy Ellis] Well, I think we’re coming out of winter, and people should be figuring out what they’re going to do for the summertime. It doesn’t even have to be about work. But if you’ve been trapped in your house and not leaving it for the last six months, probably you should think about getting out for my sanity and yours.
[David Spark] Let me also… Not just that. You had told me when you were at your previous employer that you forced people to take vacations. If they hadn’t taken one in a certain period of time they were required to take a vacation.
[Andy Ellis] Yes. Yeah, keep an eye on your staff. If they haven’t taken vacation time… This is what vacation time is for. If they’re afraid to take vacation because the business is going to go on without them, you should think about doing like quiet Fridays. No email on Friday so people can disappear on vacation, or even better a corporate wellness day where everybody gets the same bonus day off.
[David Spark] Not a bad idea. Ori, anything specific you want to tell our audience about CYREBRO? Are you hiring over at CYREBRO? Do you have an offer for our audience from CYREBRO? Let us know, and how to connect with you.
[Ori Arbel] All right. Well, if people want to know more about CYREBRO, obviously you’re welcome to visit our website, Facebook. We’re all over Twitter, all of the social media. And that is it. Exactly, io. Yeah, exactly. So, you can go and visit us, and read more about what we do. The website has marketing people that are way more in the weeds of selling CYREBRO. I can tell you in a nutshell what we’re aiming to do, what we’re set up to do. CYREBRO was meant to take the traditional SOC as a service and make it into a product. Make it into something that’s accessible and caters for everybody. We’re taking enterprise [Inaudible 00:31:34] cyber security strategies, and we’re catering the SMB market. We’re taking it, and we’re making it available for everybody. That’s what we’re trying to do. We’re trying to empower the market that was neglected for years. Everybody deserves to be protected, and that’s what CYREBRO is set up to do.
[David Spark] Excellent. And you are hiring, correct?
[Ori Arbel] Absolutely, always. Always. You can hit us up on the website as well.
[David Spark] So, if you’re looking to work with CYREBRO or have an enterprise level SOC solution or the SMBs, please check them out at CYREBRO.io. Thank you very much, Ori Arbel, for sponsoring the CISO Series. Thank you very much, Andy Ellis, as well. And thank you to our audience. We greatly appreciate your contributions and listening to the CISO Security Vendor Relationship 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, CISOseries.com. Please join us on Fridays for our live shows – Super Cyber Friday, our virtual meet up, 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@CISOseries.com. Thanks for listening to the CISO Series Podcast.