David Finn:

Hello, everyone. My name is David Finn. I’m the Vice President of CHIME, responsible for the three associations, including the Association for Executives and Healthcare Information Security, and it is my pleasure to be speaking with Shankar Somasundaram, the founder and CEO of Asimily. Shankar, my first question because we’ve known each other for more than a minute here is when did you first realize that biomedical devices, I know Asimily looks at everything on the network now, but the biomedical devices were the driver and when did you understand that they were different…they needed different attention around security and a different approach?

Shankar Somasundaram:

Thanks, David, and a pleasure to be here talking to you. As you know David, I used to run the IoT business at Symantec and this journey has been going on for a long time. At Semantic, I spent a lot of time and this was more than a decade ago and it feels like a long time now, we started working with manufacturers and medical device manufacturers. We started talking to hospitals and when we were doing that, what I found was that the manufacturers always viewed the risk on their devices very differently…the vulnerability very differently…the attack surface very differently….from the way the health systems viewed that. And as I dug further and further into it, I started to realize that there was a lot of truth to that because the devices were built differently. And as I dug further into why there was a difference in opinion, I realized there was some truth to that because of the way there was a difference in the way the devices were built. They were the differences in the way the devices were constructed and configured. There were differences in the way the devices were connected. And because of that, the traditional security approaches in every dimension, whether it is inventory or vulnerability management or data loss prevention or threat detection, everything needed a different approach, whether it is forensic analysis. And because they have constraints which were different from IoT devices, they had certain things which were better than IT devices in terms of how they were hardened. Overall you need a completely different approach to security and that’s a journey I figured out at Symantec that wouldn’t work. And we did some things with Symantec, at that point, to cater to those who wanted medical devices [security], but I think to solve it in a bigger and better way, I decided eventually to start Asimily to have a greater focus, to really solve it across the stack. But it’s that journey of Symantec which actually taught me that these medical devices were unique and also understood why they were unique and then became clear and apparent that you needed a completely different approach.

David Finn:

The risks are certainly unique and different. Moving from the device makers to the providers, I don’t need to tell you that, security is not just one thing in a healthcare provider. So how do you get different organizations to work together, whether it’s Information Technology or Information Security or Biomed or the Networking group themselves? How do you get those all the work together to manage the devices, even though they have different sets of risks?

Shankar Somasundaram:

That’s a great question, David. The first thing they’ve to realize is a lot of people in the industry see them as antagonistic to each other and that they are butting heads against each other. The first thing to realize is all of them are working towards one common goal. They all want to keep patients safe. They all want to make sure patients are enabled. Networking is doing it in its own way. Without the network, you can’t have real patient care. Without IS, you cannot have patient care. Without Biomed, you cannot have it. They all want to do it the same way and they have the same goal. That’s the good news. But they have different backgrounds, they have different experiences, and their understanding of the problem is different. They view the data very differently. And that’s where the difference of opinion arises. It’s more tactical than it is objective, which is more solvable. And to really solve the problem, you really need to show them the same data in different ways that they can understand it and they are used to.

So for example, from a Networking perspective, they understand more in terms of flows, in terms of your policies, in terms of packet captures… forensic analysis, that’s the world that they have lived with for many years. And that’s a world if you show them, they understand the problem that way. From an IS perspective, it’s really around vulnerabilities, mitigations, anomalies, and threats, they understand it that way. And from a clinical perspective, it’s really around inventories but they really want to understand and get a hold of inventory. For them, just because the device has an older operating system, does not mean that it needs to be replaced. There are other factors to it. They have other factors like recalls that they need to consider [like] which devices need to be replaced from an operational perspective. So it’s really different views of the same problem that they are all really looking at and understand. And if you give them that data in different views but in a common framework, in a common portal, then they start to see the other person’s side and view as well. Because they understand that hey, you know that just because it is an old operating system, you don’t have to replace it, and here’s the data. Having said that, Clinical sees that there are certain older operating systems you gotta replace. They also understand the networking challenges that come along with it and networking sees some of the challenges that IS and clinical have to face. So they start to better understand the problem each other faces. They also see how they can actually achieve their final goal, which is important. And then they start to better align because now they’re getting the data they want, they understand the challenges of the other team and they can still achieve the goals is what becomes very clear using the data. And I think that is what starts to bring them together. So you have to solve the problem in three or four different ways and display the data properly to the right team and that really starts completely together to really solve the problem.

David Finn:

Yeah, I think you hit the nail on the head. The real risk, the ultimate risk, is the patient and while we may have unique needs depending on where we come from, the bottom line is keeping patients safe and care continuous. Great point. I appreciate it. I do have, in my role at AEHIS, I talk to a lot of CISOs on a daily basis, and so I’m gonna give you the number one question I get. How do you ask for budgets when the market is soft and by that I mean we’re technically in a recession? Providers are cutting back in order to respond to that. But you still need to provide protection. So what’s the answer to that? What’s the trick to asking for money?

Shankar Somasundaram:

I think this is a tough question. I’ve been talking to a lot of people, CISOs and CIOs as well, as to how they are asking for budgets in this market. And I think I’ll tell you some of the things that other CISOs are doing and I’ll talk about some of the things that we recommend to do as well. One of the things that some CISOs are doing is they are actually listing out what are the risks that the organization faces but they are not doing. Something like in a month there are 20,000 vulnerabilities that get published. What is the risk of not addressing them? What is the risk of not mitigating your highest priority risk? What is the risk of not monitoring for threats? And, an average medical record, you know this David very well better than I do, sells for 10s of dollars and sometimes hundreds of dollars in the black market. An average incident is now $2 million. So there’s a huge impact of actually not doing something in the environment. Some of them, the CISOs and the CIOs, have been able to quantify or at least give a rough [estimate] of so many medical records. This is the risk we face and these are the entry points we face. This is why we need to do it. That’s option one.

The other thing we recommend for many CISOs and CIOs is benchmarking, a rough benchmarking. For example, at Asimily, we show you an organizational risk score that you can compare with other organizations. And so basically what that allows you as an organization to do is actually compare how good or bad you are with the rest of the industry. And when you do that with the industry average, you can actually get a rough idea of this is my gap in terms of security posture and there’s more coming on that. But this my gap in terms of security posture. Because one of the things that the board will always ask is I’m spending so much on cybersecurity, how good is good enough? That’s the question. They actually stop. And so you have a chance to say, you know, this is the gap I need to fulfill. And this is what I need to do and that allows you to benchmark, allows you to give us better quantifiable answers to the board.

And the final thing, is a lot of people have been using attacks that have happened since systems that have been in the news to kind of benchmark where they are. They get it from the Joint Commission on where they are. And we help healthcare systems with what kind of security controls they have and use that to understand what they need to do and understand the gap. And they’re able to go to the board. So a little bit of pure information there also helps directly from your peers or we have some other information which then allows you to determine, OK, this is the gap in a posture which would effectively cause us to have the same problem and then get it really sorted. So it’s really a combination of making the board understand risk inherently in a quantifiable form, really benchmarking against the industry to say you know there is a place for improvement is where we need to go. Security is never gonna be perfect, but you need to keep improving. It’s really raising the bar. That’s all it is. And then finally, I mean you have real quantifiable data and control some of the controls that other organizations have had unfortunate incidents then you can use that also to benchmark yourself. Some of that data is also available.

David Finn:

Very good you. You mentioned vulnerabilities so I’m going to go off in that direction. With mandatory reporting for device makers on vulnerabilities and issues like that, we’re seeing more and more vulnerabilities being reported around the medical devices. What do you do to reduce the risk from those vulnerabilities especially when patches are few and far between? Even when they announce a vulnerability, often there’s no patch for it. They’re just warning you about it. And a lot of providers haven’t dealt with network segmentation or micro-segmentation. It may not even be an option for them. So what can a provider do who doesn’t have patches and isn’t highly segmented?

Shankar Somasundaram:

That’s a great question again. So here I would say, this is where I think goes back to your original question, right, medical devices are unique. Biomed devices and even many of the IoT devices are unique. You can’t take the standard approach of IT which is to go patch everything …patch Tuesday and patch Friday. You can’t because very few patches are available. You know that, I’m hoping many of the listeners will know that as well.

The other problem is segmentation and micro-segmentation. I mean, I’m not saying you shouldn’t do it, but there are challenges in doing it. And even when you do it like maintaining those segments, I mean you’ve been in the industry for a long time, you know the challenges of doing that. We have health systems that are saying they’ve been doing segmentation for five years now and they are still at stage one or stage zero I would say. So how do you really solve it?

And so here I think you really got to understand… the good news about medical devices, this is where the uniqueness of medical or some of these ICS and IoT devices come, they’re configured very differently on the network. They are hardened very differently. And they’re connected very differently. If you really analyze it with something like the MITRE ATT&CK framework for that device in that environment, you will find that the parts for the attacker are much more difficult and different than compared to an average IT device. It’s much harder to reach the device in many cases. There are only certain paths for the attacker and this changes from my environment to environment. So if you do the analysis on how an attacker can take advantage of my device in my environment, you’ll find there are only so many things the attacker can do to take advantage. And there are probably five or 10X exploit parts that are critical in that environment. And what you can do if you can’t really segment, but if you still have the NAC of the firewall, you can apply targeted policies which are not segmentation, which are specific, simple policies you can apply on the devices on the network. That’s option one that can minimize the path of an attacker or mitigate the path of an attacker so they can’t really take advantage of the device.

Option two is some of these actions can be taken on the device itself because a lot of what causes the device to become exploitable or attackable really can be mitigated with the device itself. And so some of those you can verify with the manufacturer. In almost all cases, our experiences…we have found that none of those are really required for the clinical operation of the device. So you can also take action on the device if you have absolutely no capability on the network. And so you really don’t have to do segmentation, micro-segmentation. I still say you can do it, you should do whatever you can, but you don’t have to do it and break your head over it day in and day out. You can effectively block the exploit vector parts on the network or on the device and wherever you can do segmentation, you can add it as an additional layer on top of it to really make sure you’re secure.

David Finn:

Shankar, over the years I’ve done a few desktop exercises with executives from across the healthcare system and as we exercise those incident response plans invariably and because I have a special affinity for medical devices, I always throw that one in and the eyes lays over and the stars go blank. So how do you recommend a provider organization’s plan and incident response program as attacks against these systems are increasing the medical devices. Not only plan it but how do you execute it?

Shankar Somasundaram:

Basically, there are two parts to an incident response program. One is really the process and one is the technology and both are important. I’ve seen a lot of health systems where they just have a process on when they will say when an incident occurs, we will contact legal, legal will contact the FBI. That is good, but it doesn’t really solve the problem. You really haven’t responded to the incident. You have just informed the people that an incident has occurred. You need that because you need a chain of command. You need to know who does what, what is the role of networking, what is the role of IS? What is the role of clinical? You need to know everybody’s role in this. And you need to know who reaches out. What places do you reach out to regulate? And so that is the first piece. You’ve got to have the process in place to know who does what, how does your incident response work, who will reach out to regulatory authorities, what is the scale of the incident, and the different escalation paths.

The other piece is really problem solving. I was having this interesting discussion with some very senior leaders and I asked him what’s the number one problem. When you get called for incident response and they told me the number one problem in healthcare, is with respect to evidence is lack of data. Organizations call us, they have absolutely no data and they’re asking us to find the root cause of the problem. We cannot scrape the devices for data so what do we do? We spend months, weeks and we just trying to get data by the time the attacker is left. So we really finding a needle in a haystack. So you really need the ability to capture data at the time of the incident. If it’s on the network, it’s still immensely valuable data. If it’s on the device, that’s the same thing, you can do that if you can. That’s going to be very challenging. But you gotta be able to capture data at the time of an incident, at the time of an anomaly, at the time of a threat on the network store it. Because 50% of the cost that these incident response forensic investigators actually charged for is actually data collection. And that was a startling fact that I actually gathered recently. So if you are spending two million, one million is just on data collection because that’s the amount of effort they have to do and the remaining million is just to do the root cause of the problem. If you can solve the problem you really are a leapfrog. You can move faster, you can find the attacker faster. The Average attacker only stays in the environment for 48 hours. You can capture the attacker’s data faster, you can move faster, you can restore your system faster and you can spend a lot less. You really need that ability and then some ability to analyze it and get it. So that’s really the process that you have to set, but it is also your ability to capture some forensic analysis because the statistics on that are alarming today. If you don’t have that capability you’re putting yourself at the backend.

David Finn:

I am going to go from the backend of incident response to the front end. At our AEHIS Forum a couple of weeks ago, our opening keynote address was “IRR is for intentional resilience, not incident response” because the best incident response is not having to do one. But how do you get ahead of the security curve as new devices are getting connected and brought in and and now it may not even be devices in the hospital and it may be wearables? It may be things patients want to connect to their chart and all that is gonna have some impact. So what do you need to do to avoid having the incident response?

Shankar Somasundaram:

That’s a great question. So yeah, I mean that there are two things here. A lot of people think that the responsibility only comes in when the device is connected to the network. But the reality is your responsibility comes in the moment you start talking to the mentor about the device. That’s where your responsibility starts because otherwise, you’re always chasing the problem. And so I think the first step you really have to do is you’ve got to start at the pre-procurement or the procurement process and you’ve got to look at the device at that stage and understand what kind of device you’re buying. What are its security implications? What kind of configuration guidelines do you have to put in place for that? What kind of security hardening guidelines do you have to put in place? What kind of mitigation controls have to be in place as soon as the device is connected? So that’s one very big aspect of it. The procurement risk has to be put in place even before you connect the device to the network. Your controls have to be in place. Your configuration baselines have to be in place. That’s one.

The second thing is I think you need to think about some level of standardization across your network, that people don’t even know how the devices are connected. There are certain models, certain configurations you can say these are the ports that I’m going to allow and if it’s outside of these ports, I’m going to effectively have an alert to go to have certain configuration guidelines. You can’t standardize medical devices, but you can have some idea about how these devices operate. And then finally, I think if you monitor the source as the devices come up, you monitor which new devices come into your networks. You don’t have to wait for the problem to occur. You don’t have to wait for the vulnerability to show up, you can actually preemptively start taking action. So the answer really lies in going to pre-procurement risk analysis and doing risk analysis. Doing the risk analysis before the device is connected and then monitoring devices even before they actually make a vulnerability.

David Finn:

I’ve got one last question for you, Shankar. You have been out spreading the word for many years now and a lot of healthcare providers are actually figuring out this is an issue. We’re seeing a great uptick in it. But for some of our providers, particularly smaller ones or those that haven’t been able to get the attention of the executives, what’s the first thing they need to do to get this build into their program? How do they convince executives and raise awareness within their own organization about these issues and concerns?

Shankar Somasundaram:

I think it is a hard problem to solve and small organizations have a limited budget. They don’t have to eat the entire piece [at once]. They don’t have to say I’m going solve resilience all of these ten things. I am going to resolve vulnerability inventory, anomaly, and threat detection. You don’t have to throw the kitchen sink at it. You break it into chunks at a time to effectively show progress in small little chunks. A lot of people will spend $5 million on a NAC solution and then management laughs, where is the return? If you break it into small chunks, you spend a small amount of money on say one piece. Let’s say I want to gather my inventory. Then you spend a small amount of money on vulnerability management so you can actually start showing progress in smaller chunks to your management. And that then convinces the management that you’re moving forward. That’s part one. And again you got to go back to the thing: how do you get a budget? It’s a combination of what I mentioned on how you get a budget, but in smaller organizations, it’s also about breaking it into chunks at a time instead of trying to eat the entire elephant. And I think that’s what you do when you’re a small organization, convince the management that you’re actually making progress, you are actually bringing down the risk, and here is the way you’re bringing the risk, and here is where you stand against the rest of the industry.

David Finn:

It’s a pleasure as always to talk to you, Shankar. I always learned something. Any closing thoughts or words of wisdom?

Shankar Somasundaram:

This is a multidimensional problem. It’s not as simple as a solution and here’s a silver bullet and everything is solved in the world. I think security is a continuous process. Also, remember to all the readers that what you do today has to continuously evolve. Whomever you partner with also has to be evolving all the time because you are with the stagnant [partner].. if you’re stagnant, your attackers are not stagnant. You have to think of IoMT security then as an evolving journey. You’ve got to partner and you want to have processes that are also evolving to keep up with the industry.

David Finn:

Absolutely. We live in a world where doing the same thing is really doing nothing in terms of security. So thank you. I appreciate your time. And look forward to seeing you again next time.

[end]