Erik: Shankar, thank you for joining us on the podcast today.
Shankar: Thank you, Erik. Thank you for having me here. A pleasure to be here.
Erik: Great. Well, I'm looking forward to this one. My wife is in the industry, in the healthcare industry. So, I get to listen in on a lot of her phone calls, and I try to educate myself through osmosis in that way. But I'm really excited here because I've been talking to a number of cybersecurity companies recently. And for the most part, they tend to be fairly horizontal. I always think it's quite interesting to talk to a company that is quite vertical, at least in their origins, even if you extend in the future. So, I'm looking forward to the conversation, Shankar. Thanks for joining us on the podcast.
Shankar: Well, it's great. Not many people understand the challenges in healthcare and understand health care is such a big part of our ecosystem, of our daily lives, that securing the healthcare environment is a very important aspect. I'm glad we're able to talk about this topic today in greater detail.
Erik: Yeah, I think a lot of people don't know this. But healthcare in the US, it's something like 20% of GDP. If the trendline continues, it's going to be like 50% of GDP by 2050, right?
Erik: Hopefully, that doesn't necessarily continue. But yeah, it is really a massive part of the economy. I know that your background is a bit more varied. I guess, most recently, before founding Asimily, you were senior director of Internet of Things at Symantec — which I guess everybody on the podcast will be familiar with. I imagine that at Symantec, you were probably looking at IoT from quite a broad perspective, right? Symantec is in all sorts of different industries. What was it that led you to think, first of all, you want to set up an independent company focused on risk management, and then that you wanted to focus specifically on the medical space?
Shankar: Yeah, that's a great question. In Symantec, like you mentioned, I was looking at a number of different verticals — industrial, automotive. Healthcare actually was part of that list, and retail as well. When I was looking at all these verticals, obviously, you talk to a number of customers. You talk to partners. You talk to the people in the industry who are regulators, and you understand the challenges faced in different verticals. I found healthcare to be pretty unique in that sense, in the sense that there are a number of regulations in healthcare around privacy data protection that you have to adhere to, the number of challenges that there are there.
Healthcare — I don't define healthcare as a vertical. I define it as a system of systems. When you look at healthcare, it has not just the elements of medical devices. It has IoT devices. It has industrial devices, OT devices that you would find in a general building like elevators and building management systems. Then they're all connected in a mesh. So, you really have pretty much every possible flavor of device in combination that exists in the environment that all needs to be secure. Any one of them can be an entry point for an attack. You also have to make sure that they work efficiently, because healthcare costs otherwise are pretty large.
This healthcare vertical presents a very interesting and challenging problem, which I realized that traditional IT solutions don't really solve for. Obviously, OT has its own challenges. But healthcare, like I said, is a system of system which has a set of challenges. It doesn't really get solved for. To me, it felt like there is a need for a different way to build the solution. Whether you're doing risk management, or incident response, or whether you're looking at how do you actually effectively manage the device holistically, I felt like a completely different approach was needed.
At that point, Symantec was also going through a transition. Remember, it was at a time when Symantec was acquired by Broadcom. Sorry. It wasn't acquired by Broadcom, but it was acquired by a private equity firm. They were starting to reorg the entire organization. And so, we realized that Symantec was not in a position that it could focus double down vertical, expand its capabilities in that vertical. Then the kind of products needed were also going to be slightly different. It required a fair amount of investment, a fair amount of re-architecting. It didn't feel like Symantec at that stage was in a position where we could go after it. And so, I decided that I would break off and re-think the idea completely by myself. And that led to the origin of Asimily, where the entire architecture, the idea, everything had to be redone and rethought — which I would be able to do much more effectively outside of Symantec. And so, I left to do that. That's how Asimily was born.
Erik: Yeah, I see it. I guess, right now, across different technology domains, we're in this era of constant disruption where there's always something around the corner that's challenging the incumbent companies and providing room for new companies to grow. But cybersecurity seems to be somewhat unique or uniquely severe in that stand. In that, unlike in a lot of other technology domains where technologies develop and then people bring product to market, cybersecurity is almost warfare, right? So, there's really this ongoing battle between, let's say, the white hats and the black hats, which puts an intense competitive pressure to evolve. Maybe that's one of the reasons why we see so many new companies emerging here. Because there's just new new threats that are emerging that somehow need to be addressed and maybe addressed with different tech stacks.
When you talk about reinventing the business to address this set of issues — if we think about the business architecture, we think about the underlying technology. Then we think about maybe the applications and the services, and then the business model, et cetera — what are the areas that you saw or thought at Asimily, we really need to focus on reinventing this part of what a cybersecurity company is, in order to address the threats that are not currently being addressed well in the market today?
Shankar: First of all, from an attack surface perspective, like I said, healthcare is extremely heterogeneous. I mean, it's probably the most heterogeneous vertical that I have seen. Like I said, I have experience with industrial, automotive, retail, many others. It's the most heterogeneous vertical that I have come across. That creates, like you said, attackers have immense attack surface to go attack the system.
So, if you look at it from a technology, a different functional perspective, there are a number of areas that needs to be re-architectured. You start with vulnerability management, which is how do you really — now you have so many devices. So many of them are legacy. So much heterogeneity. How do you really do vulnerability management in an environment like this? We cannot scan a lot of these devices. Because if we scan them, they don't operate. We have had case studies where people have scanned devices, and the gain of the ECG has completely changed. And you can no longer use that ECG device in the environment. So, we cannot scan a device. It's vulnerable. How do you really figure out which are your most critical devices in the environment? Which are your most critical medical devices? Which are your most critical industrial devices? Which are your most critical IoT devices? When you group them together, how do you figure out your most critical devices across all of them? Then how do you really mitigate them? Because if we got to segment and micro segment every device in the environment, it could take you years to do it. So, that was problem number one, where how do you do vulnerability management has to be rethought and re-architectured. It's something that we have done a lot of work on, we have case studies on. And it's something that we excel at.
If you look at incident response, for example, how do you do incident response? In a normal IT environment, you would just scrape the device if there was an issue of the device. You scrape data off a device, and you would analyze them. You can't do that with medical devices. You can't do it with a lot of industrial devices. An average attacker only stays in the environment for 48 hours on top of it. So, when you combine the constraints with these devices and the issues around how these attackers operate, how do you really do incident response? How do you monitor the devices? How do you find the issues in the networking, in your network data, if you think there's an issue? How do you collect data if there was a potential incident? All of these requires a different way of approaching the incident response problem. Again, it's something that we have spent a lot of time on, worked on, and really re-architected. Look at inventory. How do you really capture data? How do you analyze them? Inventory is a problem that many companies are falling, including us, on how you would actually gather most effective data, with the traffic that's on the network, with other sources that is not otherwise doable in the IoT network.
When I started Asimily, I build this team around us and we said, "Okay. We got to reimagine different areas of the technology stack." Because every area of the technology stack — whether it's inventory, vulnerability, incident response, data loss, and there are other things we're looking at in the future — all of them require a re-imagination of the technology stack. Then the delivery of those services also do require some differences. Healthcare is an area where maybe the operational capabilities, to take all of the different technology capabilities may not be there. The operational staff may not be there.
In this kind of environment, when you don't have all the operational stuff, how do you deliver it? There are specific partners in healthcare that can actually add the service value on top of our solution to make sure that the healthcare technology organizations can fully utilize their capabilities, can fully leverage it. So, how do you deliver these capabilities in a form that the organizations can absorb it and make full utilization of it? It's, again, a difference between the way you approach some of those healthcare versus traditional enterprise verticals. That required a change in thinking as well. It was an imagination, a re-imagination of the technology stack itself, different aspects of it, and some elements of go-to market. So, I would say the technology stack re-imagination is far bigger than the go-to market piece of it.
Erik: Just so that I understand more accurately how you're thinking about the market. If we think about healthcare, we have the traditional healthcare environment which is a hospital or a clinic. It's a highly regulated, controlled environment. Of course, there's a lot of heterogeneity within that environment. Now, more and more, we also have home health care. So, we have home devices that might be more consumer but might still be outputting data that's been ingested by some kind of healthcare system or not. Or maybe it's just being used by consumers, but it's still being used by them to make medical decisions or analysis around their health. Then we also have platforms, which are not really an IoT system but more of a strictly IT system. But nonetheless, that have critical data moving on them. So, kind of apps for communicating with doctors, et cetera. To what extent are you expanding outside of the traditional medical facilities and addressing these kind of home care or hybrid environments.
Shankar: Home health care, obviously, is growing in volume and size. More and more patients prefer to be treated in a more comfortable setting. There are more studies around this as well. We are looking at it. This is an area, of course. The technology stack is very similar to how you treat the devices within the hospital. There are some differences in how you would deploy, how you would gather data. But overall, the way you solve the problem is very similar to the hospital setting.
This changes, obviously, how you would reach out. You're not going to have a consumer buying a glucose meter and then buying an entire cybersecurity solution on top of it just for one glucose meter. How you actually protect these devices in a scalable form is something that will change, compared to the hospital environment. So, that's an area we're looking at. Basically, it's something that is still evolving. So, we're still watching and seeing how we can address that market. But a lot of what we do today will directly apply to it, as well. Certain areas, like I said, that we are — largely, a lot of things we do on the technology side apply on the go-to market side. There are some changes that will be required. And so, it's something we are observing and talking to some players in the market on this problem as well.
Erik: Okay. Got you. There's a few more questions I want to address around the industry more broadly. But before we get there, I'd love to understand a little bit more specifically what your company is providing. And so, on your products page, you have a list of the different — to me, they look like kind of modules. So, vulnerability management, inventory, device relationships, forensic analysis, policy management, device tracking. These look like front-end applications that somebody might use to assess the situation, make decisions, et cetera.
So, if you can help me break down, what does it look like on the back end? Is it kind of one platform with multiple modules that somebody can opt into on a more of a SaaS basis? Is there a hardware layer that you're providing, or are you providing a pure software on an existing hardware base? Are you doing on-device deployment, or is everything kind of cloud-based, on a more of a traditional IT system but then ingesting data from devices? What does that architecture look like for Asimily?
Shankar: Let me just walk through that, on the overall, what we provide in the architecture. We are a software solution. We run in the cloud. We also have the capability to run on-premise on a customer server. There are cases where a customer is not yet moved to the cloud, especially because they have worked a lot in healthcare. They want to be on-premise. We are comfortable with that. There is a hardware component which is really to collect the network data. But the actual intelligence and everything is in the software itself, which, like I said, is cloud or on-premise based.
In terms of what we do, it's really around inventory, cybersecurity, and operation management for medical and IoT devices in the environment. It's not just IoMT. It's also IoT. When you look at it, you spoke about a number of different aspects. I would broadly break it into four different pieces. The first one is around inventory. Inventory is really around visibility. I would say visibility is probably a better term for that piece. Because it's visibility onto what devices they are, all their parameters. Where are they talking to? What are the flows of the device? Who's reaching out into the device? Who's reaching into the device, and so on, and so forth? Everything you want to know about the device, where is it connected to? Everything you want to know about the device, all together in one location gathered by it. That is the first piece, really around visibility and inventory. It's the first element.
The second element is really around vulnerability management. There are many elements to it. Some of it, I mentioned. Like if you have a device, what are the vulnerabilities that are associated to the device? Which of them are critical to the device? Which of them can be taken advantage of by an attacker? Which of them can cause maximum harm in the network? How do you mitigate it if you cannot micro segment or segment the device? And if you can, what do you really focus on? So, there are a lot of elements to it. Then if you take certain actions, which of them will lead to the maximum impact? So, really simulating the future state of the device. All of them is really around the vulnerability management umbrella, which is a big element on how you minimize the risk in the network.
The third element is around incident response. How do you detect what's happening in the network from a threat detection or an anomaly detection perspective? How do you find the needle in the haystack? So, if you have a network with a lot of data flowing, somebody comes to you and says, "Hey, is there a server that is transmitting data, that somebody is exfiltrating data on in my environment?" You can find that information in order of minutes or seconds. How do you get that data? How do you capture data if there's an incident for forensic analysis capability? There are a few other elements. All of them perform part of the incident response.
Then the last piece is really around this asset utilization. How do you track the utilization? How many scans are done? When it's being turned on, when it's being turned off? So, you can help with procurement and planning. When you look at connected devices, all of those, I would say, are different elements that help them form the full picture. Then recently, we have this ability to do all of this for non-connected.
People talk a lot about connected devices. But the reality is, whether it's healthcare or whether it's general verticals, some percentages of the devices are connected. But a large percentage is still coming on to the network. It's not like we are 100% connectivity. Healthcare is at 30% to 40% connectivity. So, you still have a lot of connectivity coming on. We have a module that says, "How do you assess the risk of devices as you're connecting them onto the network?" How do you assess them? Is there a standard risk profile? Is there standardized bomb-like thing? What would happen if I connected in a particular way? How do you assess the risk of devices before you connect them? And how do you actually think about mitigating controls as you bring them onto the network. That's a standalone module we have as well. Together, we help our customers manage their devices, right from the time they think about procuring, all the way up to the commissioning. We are expanding that set to other things in the future as well.
Erik: Shankar, as you're explaining that, the first thing that strikes me is that a lot of the topics you're discussing are not strictly cybersecurity, but they're also about managing your fleet of devices. It's about knowing maybe what is the frequency of use. Are we using the device 100 times a day or 5 times a day? There might be instances where a device is not being used because it's been misplaced, et cetera. So, these are more operational topics. But they're topics that can be addressed by the data that you're collecting if you have a proper device inventory.
To what extent do you play? I mean, this is almost a track-and-trace topic, right? Is that a significant part of the value proposition? Meaning, extending beyond the IT team but more into the operations team in terms of how they operate and optimize their healthcare environment?
Shankar: It is an operational point. You're absolutely right. But I think in this world, when you move out of the world of IT, what people also sometimes don't see is that the world of operations and cybersecurity start to co-mingle and interact with each other. When you're in the world of IT, cybersecurity is one aspect. Operations is other. But when you move to the world of medical devices — it's true of IoT, as well as true of OT as well — the world of operations and cybersecurity are not independent of each other. They interact very closely with each other. While we saw some of the operational issues, they are required for some cybersecurity.
I'll give you a couple of simple examples. Let's say, you have a vulnerability on a device. You need to do a patch on the device. If you don't have any idea where to patch it, where the device is, if you don't have any idea — is it currently in use — you might go and apply something on the device when it's in use, and you might cause inadvertent patient harm. Knowing the utilization of the device has its own value. But it's also important for you to know when, when to take action on the device, what kind of action can you take on a device? If it's critical, maybe you cannot take an action on the device right now. So, you really have to be very cognizant of the operational impact.
The other thing could be, we have had situations where someone would say, "This is the kind of device where I have to go and apply a patch on the device in-person." If you don't even have an approximate idea where the device is in the network — which facility? If you have 10 facilities, which facility is it on? Which floor it might be on — how do you really go and do it? So, the operational aspect is tied in very closely to the cybersecurity aspect. Now, obviously, there are some nuances there in terms of, okay, you can do a lot of elements of cybersecurity without knowing all the operations necessarily. But having the operational element like we're doing the utilization, where it is approximately in your network, all of those feed in, which helps your cybersecurity get better. And, of course, added value as well.
Erik: Okay. Clear. So, they're very closely related just in terms of implementation of solutions. But then, there's also maybe standalone value on either side. One of the topics that you mentioned in terms of your offering is prioritizing vulnerabilities. This sounds like it's a unique challenge unto itself in that, let's say, there's addressing vulnerabilities. But before addressing them, prioritizing it since there's really thousands of vulnerabilities coming on every year in this very diverse device environment. Then addressing them has, as you mentioned, operational risk. In that, every time you address a vulnerability, you're somehow impacting the operational environment which could have an unforeseen impact on the device usabilities. So, how do you as a company prioritize which vulnerabilities to focus on addressing?
Shankar: This is a very hard problem. In the world of IT, you have a patch through ZIP, patch through whatever you have. Then you just mitigate the risk of the vulnerability by patching the device. You can't do that in the world of healthcare, simply because for every one vulnerability, for every one patch, they're like a thousand vulnerabilities from what we are estimating. The problem here is more challenging, like you said.
To solve it, we take a three-pronged approach. The first way is, after you match the vulnerability to the device, which is the basic table stakes. You got to do it. The first step is really — standard attacker takes advantage of that vulnerability for that device in the environment. So, that's the analysis we are doing. To do that analysis, we are researching on every vulnerability on our site. There is a ton of backend work we are doing, which is our core IP. Then we are doing an analysis. Okay. There is a vulnerability on the device based on the research we are doing, based on how it's connected, configured, capabilities. There's number of different factors. Where it's connected to, how is the topology around it? Can an attacker, whether it's in the network or outside the network, realistically find a path to the device and take advantage of that vulnerability? That's the first big question we are asking. That's a very compute-intensive operation we are doing. We are doing this for every vulnerability on every device in the environment.
We have environments which are large, where we are analyzing 20 million vulnerabilities a week. We are doing this repeated process on a weekly basis. We are analyzing it and re-analyzing it, because there might be changes in the environment that could effectively change the outcome of this analysis. If we are certain that there is a potential path for an attacker to take advantage of it, then we effectively go look at it and say, "Okay. If there is a path, what kind of impact can they create?" Again, it's based on what it's connected to, what impact does it have, what patient, what data does it store, what kind of operational impact they might have? There's a number of different factors. We say, "Okay. Can they really cause an impact in this environment?" Can they really cause real damage in this environment, even if they actually get to the vulnerability?
It also depends on the kind of vulnerabilities. Does that affect only data? Does it affect availability, patient? There are a number of other factors that relate to it. So, we really make a determination on, can they actually cause real impact? If they can do both of them, then we have over time created what we call these clinically validated recommendations for medical. Then for IoT devices, we have a set of recommendations we provide, which we know will not operate, will not interfere with the operation of the device.
You still want to be careful. You want to make sure the device is not in use. You don't want to disrupt the operation. But we know this kind of recommendations largely can be applied without impacting the operation of the device. When we do this, we have seen that we are able to make our customers 10x more efficient in their vulnerability management. That is allowing our customers to be far better, reduce their risk in terms of the risk in the environment. We're able to bring a 90% risk reduction and doing it with a 10x more efficiency compared to anything else out there right now.
Erik: What is the role of regulators in this? In some other IT domains, there's a fairly strong, I'd say, private sector ecosystem for sharing vulnerabilities. This seems more challenging in the healthcare domain because it's so fragmented. But then, I can imagine that regulators would have a strong impetus to also encourage sharing of vulnerabilities. Is there any kind of coordination across the industry? As you discover them, you share them with either device OEMs or in, some way, the ecosystem more broadly? Or is it really each company for their own in terms of building these databases of vulnerabilities and determining how to address them?
Shankar: Look, I think the industry is evolving. It's how I would put it. If you ask me this question five years ago, I would say, it felt like everyone for himself or herself, like ever company for itself. But that's changing a lot. You saw the omnibus bill. You're very aware of it, Erik. I mean, there has a series of regulations that effectively require manufacturers to do something. But that's only for devices going forward. It doesn't really affect legacy devices. Then you have the new HHS 405 D — which is more of a guideline, but it's also a good step — which talks about a number of things that organizations can do, healthcare organizations can do to look at medical devices that they currently have deployed in terms of securing. Then there's a Health Care Coordination Council, which effectively focuses on sharing information about vulnerabilities. Then there's the HSI which, again, effectively makes sure that information is populated across different organizations.
So, there are a number of different initiatives that are happening in the regulatory landscape. The only challenge with all of this is — look, I mean, every healthcare environment is different. They have their own operations. They have their own budget constraints. They have their own human constraints. It's really hard because of the differences in the environment. I say every healthcare, if you see one healthcare system, you have seen only one healthcare system. If you see 100 healthcare system, each healthcare system can be slightly different from the other. Because of that uniqueness that healthcare has with each other, it's a little hard to just create a uniform constraint across all the health systems across at one go. But there are, like I said, a number of regulations for future looking devices, guidelines for current environment, coordinating councils that focus on sharing vulnerabilities and information, HSI sites that actually focus on sharing threats. And so, there are a number of initiatives, governing bodies out there which are doing a great job of bringing pieces together.
Companies like Asimily, obviously, we are bridging that gap. We are making sure everything is put together, and it is localized for that environment so that organizations can do what is right for them. And they can focus on what is most important for them as well. So, regulators are playing a role. But obviously, there is a big space for company like Asimily as well.
Erik: Yeah, and then I guess within every industry, there's always a tension between who has responsibility for cybersecurity issues. Part of this is where legal liability falls, and part of it is more service level agreements, business expectations, and so forth. But in healthcare, does the liability and the expectation tend to fall on the device manufacturers or on the healthcare service operators?
Shankar: It's a very challenging topic, first of all. Because now you're talking about patient care and data. Both of those are such critical aspects. Data about a patient is so valuable and so important. Obviously, patient care is most important. So, when you're talking about such critical aspects, it is a point of tension between different parties. And so, it does depend. I would say, there is no one answer to this. There are different kinds of situations. If you look at a closed network in a health system which is, in effect, a critical patient care network which is managed by the manufacturer, the responsibility for that closed network would be on the manufacturer with some constraints. There might be some constraints on who can touch the device, what can you do with the device. Any violation of any of those constraints could effectively invalidate the manufacturer's responsibility.
When it comes to devices which are outside of these closed clinical networks, a large part of it does fall on the health system itself. Because the health system uses different people to touch it. They use it in ways that is more suited for their environment. And so, the health system then takes on a lot of responsibility for those. That's where service providers sometimes step in, where they take on some of that ownership. They take on some of the cybersecurity responsibility, where they effectively say, "We'll manage the device end to end for you." They kind of bridge some of that gap between the HDO and the manufacturer. There is a set of players who do that as well in the industry.
I would say, in that sense, the responsibility on who really owns the cybersecurity for the device does depend on what is the device, how is it used, how is it architected inside the environment, how old is the device? So, there are a number of factors that depend on it. But I would say, largely, today, it still falls on the HDO, the actual hospital in other ways. In some cases, it falls on the manufacturer. In some cases, intermediate parties also take on responsibility.
Erik: Okay. It sounds like in Asimily's case, you're mostly focused on the operators. It'd be great to walk through one or two cases. Feel free to anonymize names. But if you can give us a fairly detailed perspective on what were the challenges they were facing and how you collaborated. Also, who you were working with — I think it's always interesting to understand who at an organization is actually the decision maker, who are the users, the first or the primary, the secondary users, et cetera. Do you have one or two cases in mind?
Shankar: Yeah, sure. I can talk about, for example, this health system is located on the East Coast. It's around 1000-bed health system. Few hospitals have thousand beds. And so, this was a few years ago. They had seen an increase in the inventory of medical and IoT devices. As their inventory of medical and IoT devices was going up, they were basically facing problems in security management. They were using some traditional IT tools for vulnerability management and networking. There was a problem scaling up to use it. They had a configuration management system, like a CMMS system. The data was incomplete. They looked at it. The data was incomplete. They also wanted IoT. So, the data was very siloed. There were some medical devices, some data. IoT had some data, different systems completely siloed. They were largely outdated. I mean, you could look at it and you could say, this data doesn't make sense. The hostname, it was something they used probably four years ago. Somebody had changed the host name for the device. None of them added up when they actually went and looked at it.
You also had a lot of network segments in the environment. They had done some segmentation. They had many network segments. But they were pretty much flat at that point in time. There wasn't really any clear segmentation on medical devices in a particular area, and so on. Like every other health system, they knew. I mean, they were responsible enough to know that they shouldn't be scanning their medical devices. This is true of most health systems. Many health systems now, they know they shouldn't be deep scanning their medical devices. So, how do you really do vulnerability management? It was really a problem. It was a real problem. And so, what they were really looking, like every other health system, is how do you really get an inventory. That was step one. So that they know where the devices are, which VLAN, everything about the device. Then they can use that data to actually do some segmentation in a little more concise form.
They wanted to really get a hold of risk management, because they knew they couldn't scan this device. They knew they had a big fleet. They knew they were going to, and they have been adding more devices year on year. Now they have more than like 8,000 medical devices. That's just growing year on year. And so, they really wanted to get a hold. How do I get a control of my IoT vulnerabilities, IoT and IoMT vulnerabilities, in the environment? How do you prioritize them? Basically, like every health system, their staff was limited. So, how do you really do this with limited staff? Then they want to develop incident response processes on top of it so that they can act on it as required. And so, that's where we came in.
They actually selected Asimily. They had a long selection process. They ran two or three different pilots. Then they selected Asimily. One of the reasons they selected us was for the vulnerability management alone. One of the things — they effectively said at the end of it when we asked them, "Why did you select us?" They said, "Look, the vulnerability management and remediation that you're able to provide significantly reduces the time and effort for us to secure our connected devices." They were able to do more with less. That's what really drove them towards Asimily. But along with that, they got a full risk profile of more than 8,000 connected medical devices in the environment. They were able to know all the device attributes, the security capabilities, the network status. They were able to segment out their IoT devices now. It's still an ongoing process. At that point, they didn't have a knack when we came in. They got a knack much later. But they have been able to use the data to now start segmenting in a much more consistent fashion. They have been able to discover certain anomalies in their environment, which they have been able to address. They haven't had any major attack, thankfully. But we have been able to discover certain things that could have caused problems for them later on, indicators of compromise that could have caused issues in the future.
In total, they've remediated thousands of devices using our clinically-validated recommendation. We also provide them notice on FDA recalls automatically. So, they have been able to use that and integrate it into their process. They're using all that now. They have created baselines. If you look at their organizational risk code, which we provide, and we compare it to the industry average, they are much lower than the industry average today. When we started off, they didn't have that metric. But if you look at it at a rough level, they were at far higher risk because a lot of them had been left unaddressed. Since then, they've really reduced their industry risk. Their ability to respond to something is much faster. They have some KPIs on how fast they're responding, how fast they're mitigating. They have some continuous improvement processes they are doing, which is effectively I would put their medical device security program among some of the top-rated programs in the country, even though the resources they have is just a small fraction of many of the health systems that we're dealing with.
Erik: It sounds like a great outcome. As you're walking through the case, I'm getting curious about the business model. Because you have a lot of moving parts. You have x number. You have 8,000 devices, kind of devices managed. You have different services that you're providing. I know this is not the answer. But I'm always thinking, as you go, there's always this conversation in the US of moving from a cost per service health care model to a kind of a preventative or an outcome-based health care model — which I think might use in Japan where it's more like you pay X amount per year. And if you're healthy, that's the amount that you pay. So, it's more optimizing around outcomes as opposed to payment per service. I know, in IoT, it's still difficult to do that for a lot of reasons. But what does the business model look like today in terms of how you would try to tag the value that you're providing to the services?
Shankar: Today, with these devices, with the world we are living in, it is still cost per service. Now, that per service can be different metrics. Right now, outcome-based is very hard in this environment. Simply because you're still, in general, for any cybersecurity, anyone who's doing cybersecurity on anything. Because ultimately, the enterprise software landscape is broad and rich. There are so many different elements to it. No single vendor is a magic bullet to solving everything. So, it's really hard to say, unless you own the entire cybersecurity for that customer and you own it as a single stop shop. It's very hard to say that if something were to happen — because you don't know where the entry point was at. It might be outside of your purview. So, it's very hard to effectively say, if something were to happen, then this would not be valid. Or if nothing were to happen, this would be valid. Because if nothing were to happen, maybe you didn't do anything. Maybe some other software in the environment which was a gatekeeper did a better job. So, it's really a little hard to do an outcome-based payment in cybersecurity as it stands, because there are many elements to the puzzle.
But what you're effectively doing is, by providing certain key metrics, like how many devices. You have a rough idea how many devices should exist. Are you finding the devices you expect to find? Are you effectively prioritizing them in a way that actually allows them to focus on and reduce with? Are you giving them a task or a set of targeted recommendations? You can now start to show value.
We have another customer where they have done a study, where they have said, "Okay. Before Asimily, I was spending X number of man hours." They were actually spending a lot of man hours remediating. They looked at different solutions. They said, "With all these solutions, we still need an extra man, full man person. Then I need a network engineer to go segment it." With Asimily, they're effectively saying, "I'm spending literally, I would say, .2% of our resource in terms of managing it and very limited network resources."
So, what they are effectively seeing is, okay, without Asimily, if I had to just get what devices are there, if I had to do vulnerability management, what is the cost without no solution, complete manual. Get a person with some other solution, what was the effective cost? With Asimily, when I have to do the risk reduction, the vulnerability management, what was the effective resource allocation? This is a small health system. They saved more than half a million in costs just in vulnerability management alone. While it's not an exact outcome-based in terms of cybersecurity, it is an outcome-based in terms of risk reduction, because they are reducing this. They are prioritizing. They are actually fixing the vulnerabilities and mitigating them.
In terms of cost savings, because they're able to do it at a fraction of the resource where they're able to do it with other solutions or manually. And so, that's how we are able to measure outcome. We have case studies on that. But today, the service model is still per service. But customers are buying the solution because of the outcomes that we are achieving for them. In that sense, we are able to deliver clear and defined outcomes even though cybersecurity is a little more amorphous in general.
Erik: Got you. What is the variable for scale? Is it number of devices secured? Is it based on the number of beds, the number of users? What are the variables that you factor in when determining customer A versus B?
Shankar: Yeah, I would say, devices is one. Volume of data is two. Because you can have small number of beds, but you can have a lot of devices connected. We have seen that. And you can have a huge volume of data because maybe there are some high-end equipment which are just pumping in a lot of data. That can create a lot of traffic in that environment that you have to secure. So, I would say the two major determining factors are generally number of devices and volume of data. Generally, they're correlated. Sometimes they may not be, depending on the kind of facility you're going. We are going to small facilities where there are only certain kinds of devices which are just pumping a lot of data. And so, there, the volumes are much higher. But if you were to ask me one factor, I would say number of devices is probably the most deterministic factor of scale across most environments.
Erik: Got you. Great. Well, Shankar, Asimily is — I guess, in the healthcare industry, you're no longer a young company. It's founded in 2017. But still, this space is evolving very quickly. So, if you look out over the next 12 months, the next 24 months, what is exciting for you? Where do you see growth coming?
Shankar: I think the market is still evolving. So, that's number one. Whether it is in the US market or international, I think there's a lot of scope for health systems to be protected, to be secured. I would say the market is still evolving in the sense that the needs of the customers are also evolving. Three years down before, if you'd ask me this question, I would say everybody only cares about getting an inventory. Now there's a lot of thought on risk reduction. People are going to talk a lot more about incident response in the next year or two. I would say there's an evolving trendline.
From our side, we see growth in two aspects. We see a lot of health systems that remain, that need to be secured, that we think we can actually do a great job in helping them. We also see a great potential in additional use cases that people are going to look for beyond the traditional things that they are doing today. We are one of those companies that are continuously innovating and adding modules that most of the market isn't even talking about. As the market is maturing, we think that the huge potential for Asimily is to be able to take advantage of this need that arises in the market, and then address it in a way that nobody else is doing.
Erik: You mentioned, when we were chatting before the show, that you're also expanding into new industries, which I suppose is natural since you're already addressing a lot of different IoT devices in the medical sector. What are the new industries that are in focus for you?
Shankar: First of all, look, I think part of the reason this came out is because when we look at health care, we're already securing IoT devices. We're already securing the building management system. So, there are other environments that have similar set of devices. For example, lab environments that have similar set of devices as health care. But if you go beyond health care, IoT devices in a number of other verticals. I mean, for example, if you go to university campuses, they use medical devices. People are walking, or students are walking around. They can actually go get treated. There are also a ton of IoT devices, maybe a lot more IoT than medical in those. But those are the environments we can secure. There are other environments we are looking at, whether it is manufacturing or whether it's retail. We haven't obviously decided to go into those. But those also use the same kind of devices that we are securing today. So, that is of interest to us. We may not do anything, but that's an area that we could potentially go and secure in the future as well.
When you look at what we're doing today — whether it's medical and IoT, whether it's a lab environment, or higher-end or even beyond that — there are spaces that Asimily could go into, and really help solve some of the same problems that we're solving today, and bring some of the same differentiators and capabilities that we have today. Because we apply at a technological level to each of these verticals where the devices have constraints, and where it is challenging to go address all of them and challenging to mitigate them. And Asimily can help solve that problem.
Erik: Great. Well, Shankar, I wish you all the success in the world. I think we certainly need more companies like yours helping to secure this future. Because it's not getting easier, right? What's the best way for folks to reach out to you or to the team?
Shankar: They could just email me. Email the company email@example.com. That way, somebody from Asimily will respond to them. Or they could just reach out to me personally if they want to — firstname.lastname@example.org. Again, email@example.com. Again, you don't have to reach out to me just because you're interested in Asimily. I've been in the industry, including Symantec, for more than a decade. I've seen the evolution of healthcare, industrial, all of this. I have been part of pretty much many different regulations over the last many years. I've been contributing to many of the standard. So, I can definitely help people even from a guidance perspective, on a personal level. So, yeah, feel free to reach out to me if there are any questions or anything about the industry, where it's going. I'm happy to answer it.
Erik: That's great. Well, thank you, Shankar, for that. And thanks for joining us on the podcast today.
Shankar: Yes, thank you, Erik.