Transcript.

Erik: Roy, thank you so much for joining us on the podcast today. 

Roy: Absolutely. Eric, thanks for inviting me to be here. 

Erik: Great. So, we have a very significant topic to discuss, which is the topic of securing IoT devices and then more generally, the topic of understanding the devices, understanding their performance. But before we get into the topic, I'd love to learn a little bit more about you. I think you're coming from Israel, which has, I would say, quite a reputation in the device security space. I was just looking at the R&D figures coming out of Israel, and it's twice as much R&D per GDP than just about any other country in the world. Well-deserved reputation. When did you personally first touch on this topic of IoT devices or, basically, monitoring data coming out of physical things? 

Roy: It started a few years ago. I have background, actually. Both my co-founder and myself actually came from more of the traditional cybersecurity space, intelligence space risk management, and we worked for RSA and other companies before we started our journey and before we started SecuriThings. Then after working for corporates and startups and being around and doing a bunch of things, by the way, my co-founder was always about more of the technology. He was a developer, an architect, the team lead. I was always a product manager and managed teams of product managers. Then we just decided to focus on IoT and IoT cybersecurity. So, that's where we initially started the SecuriThings journey. We just started looking into it and exploring the challenges and seeing what's out in the field, manufacturers, end prices, system integrators, and all that. That was really the beginning of our journey. 

Erik: Actually, we set up IoT One in the same year, in 2015. And it'd be interesting to hear how you saw the market at that time. But our perspective, being based here in China was, and of the question of what is IoT, everybody, all the traditional companies, this was very much IoT 101 year. Then it's very quickly mature, just the general understanding of what we're trying to accomplish here, what the challenges are, and so forth. But when you first set the company up, it sounded like you were also exploring the market. How long did it take for you to start to crystallize the problems that you wanted to focus on solving? 

Roy: Yes, that's really true how you said it. IoT is like saying internet, mobile. It's just big. It has so many use cases, so many types of devices. It's pretty much everything. Initially, we're trying to understand terms, classify, characterize different areas of IoT. We're trying to work with manufacturers at the beginning with, again, the offering of cybersecurity for manufacturers. As you said, it was in the early days of IoT. Obviously, IoT started way before that but more of the topic of securing devices and all that. The risk started around those years. But then, over time, what we saw is that, definitely, IoT cybersecurity was interesting, and we were having conversations with manufacturers. But we decided to really go to where the demand is, where the devices are actually used, where the devices are actually deployed. That can be on the consumer space. But where we actually decided to really go into is more of the commercial, the enterprise space. That's where we really found the product market fit, and saw a need. Because these enterprises, corporate organizations have so many devices scattered all over the places, all over the place, all over the different sites. Whether if it's a financial institution, technology company, university, hospital, you name it, they just have so many devices. When we started exploring that specific area, that's where we found our product market fit and understood, okay, this is what the market needs, and this is what we're going to be focusing on. 

Erik: It makes sense. I mean, there's been a lot of press around how easy it is to hack things like baby monitors. That's a scary case, but the reality is that it's really hard to get consumers excited enough about security to pay more. But with enterprises, this is always a top priority. Where are we today in our ability to... I guess it's not just blocking people from hacking, but I guess it's understanding the device well enough to know, is it performing as it's supposed to be performing? Where are we today in our ability to do that? 

Roy: That's exactly what happened. When we started speaking with the enterprises, we saw that securing the devices is one piece of the puzzle. But even, as you said, if the devices are working, maintaining them is another piece. To the question where we are today, it's still a journey. We talk about the journey to full automation in this space. Today, when you look at the enterprises, the organizations, it's a lot of manual work. It's, in some cases, very reactive. There was just the case, the shooting in Brooklyn a couple of months ago, where the MTA looked at the footage and they found out that a few of the cameras weren't working in some of the stations when the shooting took place. But that just tells you how it is. It's just that pretty much across the board, across different types of organizations, there is a lack of capabilities to know if the devices are secure. But even more than that, even to know if the devices are working and operating when you expect them to work. Because obviously, organizations are paying every anything, from hundreds of thousands of dollars to millions of dollars to place these devices out there, whether if it's radius surveillance devices, access control, intrusion detection systems, different types of devices, if we talk about physical security. But then, there's also building management and other types of devices. Really, a lot of money being spent. But then, when you expect it to work, in many cases, you find out it's actually, it hasn't been working for a while. You just found that out because now is the point of time where you actually need that system to work, unfortunately. 

Erik: That's an interesting example. I guess one of the issues with things like security cameras is that these cameras could have been deployed 15 years ago. I guess if you're putting technology in the field today, it's more likely to have a proper protocol and really be "IoT device." But there's a lot of stuff that's collecting data and being integrated into systems that was put in the field a decade or two ago, and it has a completely different architecture that's much more difficult to manage with modern systems. How do you define the scope of your business? Do you try to touch these legacy assets as well, or do you try to more narrowly define your scope around the more modern devices that fit better into this IoT archetype? 

Roy: We're more focused on modern IP-enabled devices which are running on various networks. We're now going, really, we're focusing on the legacy types of devices. What you'll see is, within the organization, the devices are the modern type of devices. Again, IP-based connected to the networks. But what you find out is that they are IP-based. They are IP-enabled. They have been manufactured in the last few years, but they're lacking capabilities to make them really enterprise-ready. They are performing really well. They are actually devices that do amazing stuff, whether it fits your panel, with access controls and card readers and all that, or whether it fits your camera with amazing lenses, really fantastic types of capabilities. But then, when it meets the enterprise, sometimes it's either lacking capabilities or it's really hard to perform some of the stuff. Then the IT side of the house is so trivial. It's so trivial that in the IT side, you can monitor. You can maintain, you can upgrade any type of standard IoT device. It's been that way for years. There's so many different types of tools which enable you to do that. The IT teams really have a vast array of tools that they can select for different challenges. But then when you look at an enterprise and you look more of the IoT operational side of the house, then you see that it's underserved in terms of the capabilities that they have for solving the challenges, which are also a bit unique in this case. 

Erik: If you break down how does an IoT device differ from a traditional IoT system, what are the big parameters you're looking at? Obviously, there's much lower compute power. Maybe there's a higher diversity of types of devices versus traditional systems. But how do you look at the differences that are important for understanding how you need to do your job of managing these devices? 

Roy: Definitely, variance is a problem but then, also, the viewed dispersity of these devices. Comparing to standard IoT devices, in this case, you have devices which are out there in the field, whether if it's street corners or different buildings, and pretty much all over the place. You have different vendors. One organization can use devices from many different vendors and have many different models of these different vendors, and then also have different firmware versions of these different models on all of these different vendors. It's very hard to track all you have. But then another piece of this is also, part of it is the ecosystem or, let's say, how IoT devices are deployed. If you think about it within the standard IoT environment, any IoT device, there's the manufacturer. Then the device goes to IoT, and then it's commissioned to someone within the organization like an employee or a team within the organization. When it comes to IoT devices, typically, what you have is the manufacturer, you have a distributor, you have a system integrator, and then it hits the network. In many cases, organizations may have even more than one system integrator or even in some cases, the system integrators may outsource it to third parties. You find out that their situation, there are multiple hands touching these devices, placing them in different segments, different areas of the organization. In most cases, there's lack of standardization. Again, because there's so many hands touching them, and you'll see that it's just configured differently from a security perspective, from operational perspective. That's part of the challenge. That's, I think, part of the reason why it's so different from the standard IoT devices. Again, even just because of the the nature of how these devices are deployed and who is responsible for deploying them, and whether they go through IoT, or they don't really go through IoT. 

Erik: Tell me then about your value proposition here. I thought it was interesting--we were chatting before starting the show here--that you started with cybersecurity but have now also started covering other topics related to monitoring device performance like predictive maintenance. Because in the podcast here, of course, I talked to cybersecurity companies, and I talked to predictive maintenance companies. Usually, they're quite distinct. But there is, as I think about it, a very clear thread linking them. But how did it come to you to blend these different use cases into a business? 

Roy: Earlier on, as we were speaking with customers, with prospects, we identified that there are teams within organizations which are underserved. It's not your typical IT or security team within the organization. It's the teams which are responsible for these operational technologies. For example, physical security or for building management technologies. They're responsible for making sure the device is always up, running, available whenever the organization needs them. They're responsible for making sure that they have the right devices, the devices, that they're on time, working with the SIAs, and so on. What we saw is that these teams are, again, underserved. Nobody has ever built them the proper IT system that they've been dreaming of. While the IT side of the house has, again, many types of systems that they can work with, these operational teams are really lacking that comparison of an IT system for managing these devices. That's why, earlier on, we had the foundation of the cybersecurity so it was a really nice stack in terms of the underlying technology. But what we decided to do is also expand the capabilities to also cover more of the operational things which are needed, whether if it's around maintenance of devices, whether if it's around compliance and things of that nature. By the way, we also decided, "Hey, this is actually a new category. This is IoT ops, and this is really what the market needs--the notion of IoT operations or a system for that." 

Erik: Okay. Interesting. IoT ops makes sense. I mean, you have these mature systems for our more legacy infrastructure. We're getting to the point where we have enough IoT infrastructure in the field, certainly, that we have to really start thinking about how to manage it. If we look then at the industries, I guess on the one hand, it's a very horizontal challenge but, to some extent, you also have to pick your battles. What are the industries that you have decided to focus on in the early years of the business? 

Roy: In terms of when we look at it from a perspective of end customers, our focus is on the teams, which at the moment are responsible for physical security technologies. Over time, we will expand to additional operational teams within the enterprise. It's already starting to happen. Then when we look at different types of verticals or industries, then we're seeing demand pretty much across the board, whether if it's tech companies, or universities, higher education, healthcare, different types of healthcare organizations, hospitals, and so on. But then, it's broader than that. It's really from oil and gas, the retailers to pretty much every industry you can think of which has a large footprint of devices, has a problem to manage these devices today. We are, in some cases, focusing on specific industries. But the challenge is it's across the board. In some cases, you'll see it. The blend is may be a bit more around maintenance. It may be more around the unavailability of devices. It may be more on compliance or cybersecurity, but it still exists in each one of these industries. There's pretty much no organization that has an easy time dealing with these devices today the way it is. 

Erik: That's certainly the case. Are you typically selling directly to the, let's say, the operator, or are you integrating through existing solutions that the operator is purchasing or with system integrators? How do you go to market? 

Roy: We work with end customers but, typically, we work via system integrated partners. So, we work closely with different system integrators, because there's also value in the solution for them. They can provide better service to the end customers and know what's going on within the end customer environment. Again, they can basically just provide them better service and better value. So, we are moved in a channel model but at the same time, we also work closely with the end customers. We have a customer success team, which is really responsible to make sure that our customers and our partners, at the same time, are always happy with the systems, with the capabilities, using everything to the best the system can provide them, and the best service that we can provide them. 

Erik: Then if we look at it from one other perspective, which would be the perspective of scale, are you focused more on, let's say, the larger multinationals, or do you see a lot of demand from medium-sized companies? Are smaller companies also beginning to invest in this, or is there a certain threshold where it's maybe too difficult for management to take on the task, or maybe they just don't prioritize security at a certain enterprise size? Where have you found there to be the most demand? 

Roy: I can actually say the demand is across the board. Because what you'll see is, there's a correlation between number of devices and how big the challenge is, but also the size of the teams. In larger organizations, you typically have bigger teams which are supposed to manage these devices. But the number of devices are so big, that even it doesn't matter how many people you throw in this challenge. They can't do it all manually and, again, all reactively. Same goes to the medium-sized organization. They may have a team of two, three, maybe four people responsible for these devices. But again, the devices are scattered all over the place. There are large numbers and, again, it's hard. When you get to the smaller organizations, typically, sometimes there isn't really a team. Maybe more in person, which is responsible for many different tasks within the organization. That person is also the liaison to the system integrator or to the service provider. In which case, the service provider may be providing them the service themselves. So, it's pretty much across the board because of the correlation between the number of devices and how big the challenge is and the fact that, again, it doesn't matter how many people you throw in it. It's just, it won't be enough. 

Erik: That's a good way to look at it. Then if we look at your solution, what are you providing? Do you frame this as a device management platform? How would you typically communicate your offering to your customers? 

Roy: Basically, the solution helps them automate all the operations of their connected devices. In terms of the category, we categorize it as IoT ops. What the solution helps them do is from the level of monitoring the devices, at each point of time, they can know from data, which is we collect from the devices. They can know what's happening with the devices. To the level of managing the devices, they can know exactly across the board which firmware versions they have, when have passwords been rotated, what are the status of certificates, to the level of then automation and protection. In a click of a button, they can restart devices if there is any issues. Not just one, obviously. They can do on 500 devices in a click of a button. They can rotate passwords. They can upgrade firmwares. They can manage certificates. They can do pretty much everything they want. The beauty is that it's all in one consolidated platform. So, at the end of the day, what they get is one dashboard. It's the first time that they're seeing all their devices across. It can be across the city. It can be across the country. It can be across the globe. They're seeing it for the first time, all the devices in one single pane of glass. But in the same system, they're also seeing the alerts. In real-time, they're seeing what's working, what's not. Also, from the same dashboard, obviously, they can also perform the automation. So, if they see that something is not working, with a click of a button, they can fix it. Then the system also includes the concept of collaboration. So, we have various integrations with third party systems like ServiceNow. From SecuriThings, they can also send, automatically, an alert to another team within the organization. It can be the network team. It can be the cybersecurity team. It can be different teams within the organization, with which they can collaborate to solve the issues in a more timely fashion. 

Erik: Okay. Interesting. What does this look like from a tech stack perspective? Because I think it's a non-trivial problem to get all the devices integrated to the extent that you can roll out firmware updates and control devices, turn them on and off, and so forth. I guess collecting the data is maybe a little bit easier but still non-trivial. But what does it look like from a tech stack perspective and then from a self-rollout perspective on a customer? 

Roy: It's a pretty proven interesting stack from capabilities on the edge devices, whether running on the edge devices themselves, deployed, or whether if that's collecting information from the edge devices to integrations with various third-party systems from different manufacturers. Whenever we come out and take a customer, the nice thing is that we already have those integrations already created. The deployment, I'll talk in a minute about the deployment. But it helps us make a deployment really straightforward. That includes all stream processing and analytics, analytical capabilities, and where we have the risk detection models and the predictive maintenance models. Then we can automatically trigger what we call the smart alerts, and the customers can act upon them. Obviously, it's all presented in the dashboard, which is pretty, pretty slick. We are spending a lot of time on the design of pretty much every single screen in the dashboard. Because we're really, we're helping the customers, the teams really get to where we believe they should be now. Now also includes the slick dashboard and everything that we can provide there, and then also additional integrations with the third-party systems. When we deploy, to answer the second part of your question, when we deploy, everything we built in the last few years is really to enable a quick and simple deployment within the enterprise. From a customer's perspective, by the way, it's a software-only solution. So, all they need to do is pretty much spin up a VM. We deploy the capabilities on that VM, connects back to our system, and then everything automatically starts appearing. So, there's not much configuration from a customer's standpoint. It all just magically happens based on all the integrations that we have already in the system. 

Erik: Okay. Interesting. Let's dig into that integration topic a little bit more. You said you basically have a large library of integrations that you've built in advance, but the IoT space is vast. So, how does that work? You just start prioritizing the OEMs and then systematically going through and integrate it, or I guess you do this every time you do a new project, you're starting to integrate? How have you approached that? Because it's a vast ecosystem, and it's constantly evolving. 

Roy: Based on how our customers and partners feed us, and what we're seeing in the market. What are the trends, and what we should be focusing on? That's exactly part of the focus of the product management team--to analyze all that and decide, okay, these are the systems we need. We're already covered. These are the systems we are adding next quarter, and so on. But we're already at the point where we cover pretty much everything our customers need. Then if there's any, every now and then, something we don't support, they will help us prioritize. They will say, "Hey, guys. It will be really cool if you can also add this system that we already have, or just so you know, we're about to deploy this system next quarter. If you can have it about the same time or even a quarter after, you'll be great. Because we want to feed everything into the system." So, it's really a partnership with both our customers and our partners to work on that roadmap together to improve the system for everyone, for the purpose of really helping everyone. 

Erik: Great. That's a tremendous effort. It's super valuable. I've got a friend who's running a point of sales device now. The value proposition is making offline retail as transparent as online retail. They spent four years integrating 10,000 different point of sales transactions in the market. Now they've got a great solution. Because you just plug it in, and it works. But then, from the deployment perspective, I guess everything is IP. You said, basically, you just deployed the software and things start popping up. Nobody at the system has to go through a catalogue and say, "Here's the checklist of all the devices that we have." There's no manual effort to determine what actually should be appearing on the system. It's just you're able to analyze the data or the system's pinging and determine what devices are what and say like, "This is a camera. This is a gateway, et cetera." You're able to automate it. 

Roy: Exactly. One of our core values in the company is simplicity. One of the things which were important for us is that whenever we deploy, it's really straightforward for the customer. That means, you're just deploying the software. But it also means once that the software is up, then the system already takes care of everything. There's not much manual configuration from an end user perspective. As you described, the system knows to identify what it's dealing with and serve it with the right tools that it already has within its stack. 

Erik: Okay. Then if I understand correctly, the way that you think about the different use cases that you can support companies with is, you basically have this map of what the system is doing, the data and so forth. You create profiles based on behavior. Then if something starts acting strangely, then you can identify that it might be hacked, it might be out of batteries, it might be malfunctioning. Is that it, that you have basically a profile, and you you make predictions or assumptions about what might be happening based on the behavior of the data? 

Roy: Yes, you just got it really well. So, we have a module which is called the Smart Alerts module. That's exactly what it does. It takes all the data. It slices and dices it. But then it knows automatically how to attach the right category of alert to that event. But then, also, at the same time, decide what the severity, how bad this is, whether if it's a device that becomes unavailable, whether if it's a cybersecurity risk or anything else. But it automatically attached both the category and the severity, and then put it in front of the end user or, again, another team within your organization that they can act upon. Then with a click of a button, they can also perform the automation. So, it all works in tandem, all the capabilities within the system. 

Erik: To what extent are humans involved? I'm just thinking of scenarios where there might be a device that's turning off every 13th day. But maybe that's supposed to happen, every 13th day, somebody is going to check on, I don't know, a warehouse or something, and they'd turn off the electricity and whatever might be the case. But there could be things that are supposed to happen, but they're uncommon. A fully automated system might think that they are a fault. So, is there a need for human in the loop, or is it just putting in enough training data that eventually you work through those situations in the system to optimize understanding? 

Roy: Where the industry is now, yes, there is still a human which is part of that workflow. But part of the things we're talking about is, again, the journey to a fully automated system with the right controls in place, that the system will know, "Okay. This happened because of this and that." The system will automatically do restart or upgrade firmware or things like that, versus other cases, which will say, "Okay. Wait. It should be okay. Let's wait. Let's give it another few minutes and see what's going on." But the industry, what we're seeing is most of the industry is still in that manual reactive mode. So, even the semi-automated mode is such a huge improvement for our customers. That mode in which you have an operator who receives an alert, or he or she just looks at the dashboard, decides what they need to do, and they'd perform the task automatically. That's also pretty, pretty unique in the market today. But as mentioned, again, we believe that both us, as well as our customers, will be heading in the next few years is to those fully automated systems where everything happens. You still have a user which monitors every now and then, looks at the reports and stuff. But the thing is, it will happen automatically in the background. 

Erik: Okay. Got it. Right now, the human in the loop, how does that work? Is it that when you do the deployment, do you have somebody preemptively go in and you're embedding the domain knowledge to an extent into the system by saying, "Here's how the process should work?" Is it when an anomaly happens or something happens, then somebody in a textbox then says, "No, this is okay, or it seems to be a fault," and it's like a learning process? How does that human engagement work? 

Roy: This is our day-to-day system. This is a thing about a system, which is pretty much always open with some screens that are just there. They can see if anything pops up and other screens that they'd enter to perform actions. But then, we also have email alerts. The various collaboration capabilities that I mentioned, if they're not in the system, then they can come come back online and perform and look on alerts and perform an action. As part of the deployment and onboarding, we also train them on the system. The teams that we're working with, they really know well the devices and all the systems. I've been working with them for years, but now we're training them about this automated system that can do save them a lot of time and money with all the capabilities that we bring to the table. 

Erik: Let's touch on that topic of money quickly. So, how do you calculate the ROI? First of all, how clearly are you able to calculate that? Is that typically a very straightforward ROI where you have a few parameters and you can say, this is how much we're going to save? How clear is that, typically? Then what would be, often, the major factors in that business case? 

Roy: So, we talked about ROI, but it's actually more than just... The ROI is pretty broad. We typically like to talk about it in terms of the business outcomes that we can help our customers achieve. We like to talk about five core business outcomes, at least, that the system provides our customers and the end users. The first is really around system availability, improving system availability. As I mentioned earlier, you're paying so much money for these devices, for these systems every single year. You want to make sure that they're always up and running, especially when you need them. That's the system, improving system availability. Then there's the notion of organizational compliance. Especially now that there's more scrutiny from the IT teams, you want to know what's out there, which devices, which firmware versions, which vulnerabilities are out there on the network and be able to deal with them. Then there's cost reduction or really cost savings. It means so many things. So, less track rollouts when there's issue with the devices, less back and forth between different teams, between the operational teams and the IT teams and so on. We're seeing that so much time and money is spent today on those back and forth, in just trying to investigate and understand what's going on. Then also, another business outcome is obviously cyber protection--that's where we started--and the various capabilities which support the cyber protection capabilities in the system. The last is the concept of future planning. So, part of the challenge we've been seeing is that without having the level of visibility that we provide, it's hard to know even which devices you have and when, for example, their end of life or end of support. That's part of the capabilities that we provide so they can better plan for the future and do device refreshes and so on. 

Erik: I like that business outcome, that way of looking at the challenge. Because a lot of these things are very important, but it can't necessarily be quantified down to a straight dollar amount. Can we walk through one deployment, if you have one in mind, just to give folks who are listening a nice end to end perspective? 

Roy: Deployments, it's the same type of challenges, same type of teams that we're serving. But think about, let's say, a university, which has many devices or universities in the States. It's like a city pretty much. They have many devices which are scattered all over the campus for purpose of safety of the students, and faculty, and so on. It can be video surveillance. It can be access control. It can be intercoms in different areas. That is a typical use case. By the way, that's the same use case that we're dealing with in different types of organizations, whether if it's in tech, or in healthcare, or in other organizations. But the use case will be, how do we help the customer best make use of those technology, and make sure that those technologies that you've purchased for campus' safety always up running and available, and in the right way, and in a timely fashion? So, that's why the system will monitor all the devices, make sure they're working. If there's any issues, they will alert the end user. Then it will provide them the capabilities to perform the automation and to fix those devices, if possible, from afar. Remotely fixing the devices is a big thing with the system. If needed, they will tell them, "Okay. You actually need to refresh these devices." So, you should think about replacing them because these devices have been out there in the field for years. By the way, they're also end of life. This use cases is a pretty typical use case that we're seeing across our installed base. 

Erik: If we use that as an example, what does the sales model look like? Is it like platform plus monthly fee per device or database? Because, I guess, you're scaling up from quite small customers all the way to large conglomerates? 

Roy: We also try to keep it simple there. It's a SAS model, so tiers of devices per year. Pretty straightforward. Very, very simple. 

Erik: So, you, basically, look at how many devices a company has. And you say you volunteer 1, 2, 3, 4, or 5, and then have a model based around that. 

Roy: Exactly. 

Erik: Great. Roy, I think we've gotten a good perspective on the business here. Anything that we haven't touched on the back cover? 

Roy: No, I think this was a good chat and, hopefully, this provided enough information about what we do, and this was helpful for the audience. 

Erik: Yes, excellent. Well, thanks. Then I guess the last question for me is, how can folks get in touch with your colleagues if they'd like to learn more? 

Roy: So, there's quite a bit of information on our website, www.securithings.com. It's a website, LinkedIn page. Reach out, and we'll be happy to work with you. 

Erik: Awesome. Well, we'll get that in the show notes. And thanks again, Roy, for the time. 

Roy: Absolutely. Thanks a lot, Eric. Have a good one.