In this episode, we discuss the status of the PATCH Act for healthcare device security and the threats that it aims to address. We also explore how AI can be used to track and secure large networks of IoT devices that are impossible to manage with traditional security approaches. 

Our guest today is Greg Murphy, CEO of Ordr. Ordr is a device security platform that enables companies to see, know, and secure every connected device in their IoT, IT and OT infrastructure. 

IoT ONE is an IoT focused research and advisory firm. We provide research to enable you to grow in the digital age. Our services include market research, competitor information, customer research, market entry, partner scouting, and innovation programs. For more information, please visit iotone.com

Erik: Welcome back to the Industrial IoT Spotlight Podcast. I’m your host, Erik Walenza, CEO of IoT One, the consultancy that helps companies create value from data to accelerate growth. And our guest today is Greg Murphy, CEO of Ordr. Ordr is a device security platform that enables companies to see, know, and secure every connected device in their IoT IT and OT infrastructure. In this talk, we discuss the status of the PATCH Act for healthcare device security and the threats that it aims to address and we also explored how AI can be used to track and secure large networks of IoT devices that are impossible to manage with traditional security approaches.

If you find these conversations valuable, please leave us a comment and a five-star review, and if you’d like to share your company’s story or recommend a speaker, please email us at team@iotone.com Finally, if you have an IoT research strategy or training initiative that you’d like to discuss, you can email me directly at erik.walenza@iotone.com. Thank you.

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

Greg: It’s great to be here. Thank you so much for having me.

Erik: So, Greg, this is a really fascinating topic, I think, a very timely topic, given the challenges that we’ve seen, especially in the healthcare space, but across different critical infrastructure industries. But before we get into the topic, I’d love to learn a little bit more about yourself. I think you have a very traditional Silicon Valley background. You got a degree in history and promptly went into tech. Can you just walk us through a few of the highlights there and how did you end up now focusing on this topic of securing IoT devices?

Greg: It’s a great question. Definitely a very, very traditional kind of Silicon Valley background, you know, I had the opportunity to go to graduate school at Stanford to study American history, and, you know, when I was at Stanford, just got immersed in kind of Silicon Valley culture and some of the things that were happening in technology and the way that technology was clearly changing the world. And so I decided for myself, I’d rather work in an area and in a sector that was making history as opposed to writing history. Really started my career in actually the video-on-demand space in the hospitality world so trying to provide movies and entertainment systems into hotels and that’s how I first encountered this technology called Wi-Fi. At that time, it was very new and we were very interested in how we could use Wi-Fi to help business travelers connect to their email, into their corporate resources so that started me down the path of getting interested in networking and security.

From there, started a company to help organizations deploy and manage their wireless networks for large enterprises, colleges and universities. I helped run that company for several years and sold it to a company called Aruba Networks, that was one of the leaders in the wireless space, and ended up staying at Aruba in a number of positions. Ultimately, the SVP of Business Operations, in the wireless industry, in one of the challenges that we recognized was that an awful lot of organizations were connecting devices to these wireless networks and to their enterprise networks but really didn’t have any idea what the devices themselves were or what they were doing.

And so we started to really focus in that space, you know, and that kind of insight became the genesis for the company that ultimately grew to be Ordr. So, we, at the time, we sold Aruba Networks to Hewlett Packard. The co-founder of Ordr, yeah, was a colleague from Aruba and went immediately off and started the company that became Ordr with a specific mission of helping organizations figure out what exactly were connected to their enterprise networks and what they could do to secure those devices.

Erik: Yeah, it’s interesting to see how this kind of technology links, right? Generation to generation, and you can make a storyline, you know, of it eventually but, of course, kind of forecasting this in advance is quite challenging.

Greg: Exactly. It all started with mobility and how do we enable mobility and then, as soon as we brought mobility to the market and enabled mobility, then, all of a sudden, everyone became really concerned with secure mobility and how do you understand what devices are, where they are, what they’re doing, and that opened up a whole new era in security and that’s kind of the space that I’ve been ever since. And I think it’s one of the most interesting and most exciting areas in technology right now.

Erik: And what would you say is the status quo today? I mean, this is a topic that’s — it’s been a bit of a red flag for the broad IoT device sector for some time now, but it’s, you know, clearly still somewhat of an unsolved problem. Where do we sit today in terms of our ability to secure and also maybe just awareness of the device manufacturers and operators of the requirements for security?

Greg: You know, I think it is something where the awareness has definitely increased significantly over the past couple of years. In particular, with some of the well-publicized attacks and exploits starting with WannaCry and through some of the more recent ransomware attacks. But I think it’s remarkable that the state of the industry, the state of the world, is that one of the very few things that almost every CISO will agree on is that their CMDB, their asset database, is wrong.

They know that there are devices that are connected to their networks that are not registered in their asset database at all. They know that there are a lot of devices that are in their asset database that are no longer connected to their network. And this just happens because, you know, for years and years, the process of trying to inventory and classify devices has been very manual. They’re sending people out to attach stickers to devices and enter that information into a database or a spreadsheet. And, very often, different departments and different organizations within the enterprise are doing things very differently and so you end up with something that has been historically ignored and underinvested in. And, frankly, that is a real problem, because it’s very hard to articulate a very strong security story if you can’t actually tell and don’t know what is connected to your network.

And when we go into an environment, we typically find that the gap between what is actually on the network and what the organization knows about is usually about 15 to 20 to 25 percent. That’s a pretty scary statistic because those devices that are not known, that aren’t understood, those are, by definition, the most vulnerable devices in the organization, because if you don’t know about it, the odds are pretty darn good you’re not doing things like patching it, updating it, and making sure that appropriate security policies are being applied.

Erik: Yeah, and it’s interesting now that we have this PATCH Act, the protecting and transforming cybersecurity, cyber healthcare act coming out of Congress, because, you know, it’s one of the topics that not only CISOs agree on but actually Republicans and Democrats kind of both stand behind, you know, the goal of protecting our healthcare system. But it’s a little bit unusual to have Congress step in to look at topics like device security, right? You’d expect that there’d be regulatory bodies or the industry itself that would be taking lead here. Why do you see Congress now getting involved in this specific topic?

Greg: I think this is, yeah, kind of ultimately the indication that this really has kind of crossed over and become an issue of great concern for human lives and protecting people because if you look at the impact of a lot of recent ransomware attacks, most of the time, a ransomware attack in healthcare is really intended to cause disruption for the criminals who are behind it to be able to extract money from the hospital, from the healthcare provider.

But I think when you — anything in the healthcare environment that disrupts day-to-day operation, that prevents doctors and nurses and patient-facing personnel from adhering to their standard best practices, that, by definition, endangers human lives and that is something I think is a great, great concern to regulators and I think it’s why you start to see Congress and, you know, the Republicans and Democrats getting together and saying, “Look, this is an area that is of critical importance and we need to do something about it.”

And I think there is a very strong justification in this case for regulatory action at a federal level because if you look at healthcare devices and medical devices, there are so many different manufacturers, so many different technologies that are being used, that it is almost impossible for a healthcare provider to track all the different suppliers that they’ve got to keep up to speed.

So, having the government establish some minimum standards, say you’re going to be selling medical devices into this industry, there are some basic practices that you need to agree to, that you need to put in place so that healthcare providers have a baseline understanding of what your software contains, but also a baseline expectation of practices that you are going to put in place and maintain as a manufacturer.

So, I think it is long overdue and I think it’s because people are really recognizing the tremendous risk to our healthcare system that is posed by medical devices and by other devices that are connected in a healthcare environment that may not be secured.

Erik: And I suppose the war in Ukraine and the increasing tension with Russia kind of heightens this risk. I don’t know that we’ve seen the expected flood of, you know, additional cybercrime coming from Russia that people anticipated, but, you know, it’s certainly a prospect. Maybe we can use the PATCH Act as kind of a framework for considering, you know, what companies actually should be focused on.

So, there’s a few key elements there, so it’s having a plan in place to monitor and identify vulnerabilities and once the device goes towards approval, it’s a plan to communicate and disclose these vulnerabilities to the FDA, it’s process for patching vulnerabilities, and then also disclosing the software bill of materials to the FDA. So, those are, at least, you know, a few of the key points covered in the PATCH Act and I don’t really want to criticize the PATCH Act but just to get a sense of, from your perspective, are those things that are going to be really meaningful for the industry? Are those the things that companies should be proactively doing even before the PATCH Act is passed by Congress?

I mean, of course, it takes time, even when the parties are both aligned behind something, for an act to actually start implementing in the real world. So, are those the things that people should be already acting on or is there a separate set of activities that you would recommend companies to focus on when it comes to securing their devices?

Greg: The way that I look at the PATCH Act, because I think it is a very necessary piece of legislation, but it is not, by any means, sufficient to ensure that all devices that are connected in a healthcare environment are protected and secure. So, just for one, the PATCH Act is obviously only going to apply to medical devices themselves.

If you look in a healthcare environment, medical devices are critically important but they’re only about 15 to 20 percent of the devices that you find in a typical healthcare environment and, frankly, there are an awful lot of other devices, whether they’re video surveillance cameras, HVAC systems, building systems, gates in the parking lot, lots and lots of other devices that aren’t under the purview of the PATCH Act and can be very vulnerable so no one should be under any illusion that when the PATCH Act is passed and implemented, well, now we’ve solved the security problem in healthcare.

The other point to make is what the PATCH Act really does, you know, is it establishes some minimum standards and practices that manufacturers and providers have to follow to ensure that devices can be connected securely, like they can be patched and maintained. All of that is great, but it also requires, for that to be effective, that the healthcare providers have the ability to monitor these devices.

If they don’t know the device is there, then, no matter what technology the manufacturer has included, no matter what capabilities the product has, it’s probably not going to be all that secure if it’s an unknown device to the hospital and so it’s really critical that they have the ability to monitor and that, you know, the healthcare providers themselves are implementing best practices to maintain and operate this equipment when it’s connected.

And then I think the last point that I’d make is there’s some really great things about the PATCH Act where it’s, you know, implementing a requirement for software bill of materials, kind of an ingredients list, if you will, for the software that’s being implemented in these medical devices and that’s a big step forward, because, theoretically, it gives you the ability to understand if we know that a particular software package has a vulnerability, we’ll make it easier for healthcare providers to go and look and say, you know, “Are any of my devices impacted by that vulnerability?” and then figure out what they need to do. But that’s a huge amount of information and so this is going to also require that technology providers and software providers like Ordr step up to help organizations make it easy for them to determine what vulnerabilities exist and which devices are impacted and to help them figure out how to take remedial actions quickly so just having the information available is really important but you also need the systems and tools to be able to make that information actionable.

And the last thing that I would just observe about the PATCH Act that is really important for people to understand is that the PATCH Act is going to apply to devices manufactured moving forward, you know, once Congress passes the legislation, the FDA develops the regulations and the guidelines and they’re implemented. But, in healthcare, like in manufacturing, some other industries, you can’t assume that devices are replaced every two to three years the way we replace laptops and smartphones. Very often, you will find in healthcare that devices have a 10-, 12-, 15-year operating life and so there’s an awful lot of equipment that is already out there, billions and billions of dollars’ worth of equipment that’s going to be connected in these healthcare provider networks for many years, for decades to come and that is going to need to be secured and, you know, the PATCH Act really can’t do anything about those legacy systems. Those are going to need to be protected via the due diligence and the efforts of the healthcare providers and by software providers like Ordr and others to help make that possible.

Erik: Yeah, you mentioned manufacturing so if we contrast these healthcare and manufacturing industries, I suppose they have some similarities in terms of both having a lot of legacy equipment, they have some differences in terms of in the healthcare sector, you have a lot more guests entering facilities so I’d say it’s a much more kind of chaotic environment often, but I suppose most hacks anyways are remote, it’s not somebody kind of manually hacking a device so I don’t know if that’s impactful or not, but what would you say are — I mean, are there significant differences in terms of how somebody who is securing a plant would want to act as opposed to somebody who’s securing a hospital or are the challenges and the remedies fundamentally the same?

Greg: You know, I think, in many ways, there are great similarities. You start from the premise that in any environment, whether you’re talking about healthcare or manufacturing, you first have to know what is connected in that environment and you have to be able to understand exactly what that device, whatever that asset is, what it does, how it behaves.

If you don’t have that understanding, then the rest of your security program is really going to be on a very shaky foundation. So it all has to start, you know, whether you’re in healthcare or manufacturing, with visibility and understanding what devices are and their behaviors and then moving to an understanding and knowing about those devices, their vulnerabilities, their behaviors so you can identify, you know, “Hey, you’ve got a device that started to behave differently than it has ever behaved before, that’s something that should be of concern that you should look at,” because, typically, a medical device or a manufacturing system, they don’t wake up on Thursday morning and suddenly start doing different things and communicating in different protocols than they did yesterday. So when you see those types of changes, that’s typically an anomaly that you need to respond to. And then the really critical thing is that you’re able to close the loop and you’re able to take action once you see those anomalous behaviors. So I think that framework is very much similar from, you know, healthcare and manufacturing.

But there are very different — a lot of differences in the types of devices that are used, the protocols that they speak, so it’s not 100 percent the same, but, foundationally, the same principles apply. And I think we’re starting to see kind of the regulators pay attention to manufacturing and those other critical industries as well. And it’s very obvious, from a public safety, from a public health perspective, why they would focus in healthcare, but you’re also starting to see the government flexing its muscles with some executive orders in the CMMC, the Cybersecurity Maturity Model, being used and saying that organizations that are going to be selling to the federal government have to adhere to certain security standards and implementing policies and relying on NIST to be able to publish those guidelines.

So I think you’re seeing both the government using its regulatory power and authority but also its position as a huge consumer of these devices to force changes and to force best practices on to manufacturers.

Erik: Yeah, okay, great, thank you. Let’s now dive into your company, Ordr, and we can use that as, you know, a way also to look more at technical approaches to addressing the challenge here. So your value proposition, at least kind of the tagline on the website, “See, Know, and Secure Every Connected Device,” so that’s very simple and descriptive for, you know, what the goal is here. Before we get into technically what you’re doing, can you just share, you know, who are you working with? And I guess we’ve already been kind of discussing the problems that you’re solving but what is your basic value proposition for supporting these companies?

Greg: Sure. You know, the value proposition really boils down to that see, know, secure, that we help organizations and typically enterprises understand everything that’s connected in their environments and then to be able to use that knowledge about what’s connected to understand the device behaviors. And so that’s something that we use AI and machine learning to build the behavioral models so we can say, for example, this video surveillance camera that is deployed in a network, it really should only do the following three things, you know, speak the following protocols. Inside the network, it should speak to these one or two destinations. If it ever goes outside the enterprise network, it only should go to these very limited set of destinations.

We build that model and that understanding and that is fundamentally what allows us to determine when and if that device ever starts behaving in a way that is not consistent with its function, with the things that it should be doing, and to alert IT about that. That’s critically important, but then where we really focus and I think where we differentiate ourselves quite a bit from others is that you then now need to say, okay, what can I do about that? And if I see a video surveillance camera that is behaving badly, what can I do? Do I want to knock that device off the network? Do I just want to quarantine it, to very strictly regulate its behaviors? Do I want to protect it so I can make sure that it can’t get outside my network or that no one on the internet can access that device?

So it’s the ability to generate policies to protect these devices, to lock them down, to ensure that they only behave in the ways that they’re supposed to, that is, really, the critical component in closing the loop. So that is our value proposition. It’s really show you what you have connected to your network, help you understand the vulnerabilities and the behaviors, and then make sure that you’ve got an automated way to lock those devices down and to protect them and ensure that they only do the things that they’re supposed to do.

Erik: And I suppose one of the challenges that companies face in securing their devices is that it’s a fairly messy environment, right? You have the OEMs who understand, you know, the hardware, the firmware on the devices quite well but then don’t really know how they’re going to be used in the real world. You have the IT teams that understand the network infrastructure but might not understand how each device is being used. You have the operators who understand how the device is being used but don’t necessarily know anything around the network infrastructure or the cybersecurity challenges. So you have these different stakeholders that all have their own expertise and kind of fit into this so you’re providing a platform to address this problem. Who would be the users — who are the buyer decision makers, and then who will be the users that would be there managing or providing input into this process?

Greg: One of the key challenges as to how we got into this situation collectively is that there are so many different stakeholders that have insights into certain aspects of the devices. So, in healthcare, for example, you might have the clinical engineering, the biomedical team that is responsible for maintaining and servicing and operating the medical devices and so they care deeply about where these devices are located and whether they’ve been patched and updated and whether they’re in service and how much they’re being used.

Then you’ve got the security organization that’s really concerned with just how do I know about any vulnerabilities on those devices? They don’t care about the same things as the biomedical organization. And then you’ve got the networking team that is responsible for making sure that those devices are connected and that they can get access to the information they need.

So, all of these different groups need a particular set of information about these devices for their own job purposes and, very often, what you find is they end up having separate tools and separate systems. So you may have, you know, the IT organization with its asset database and you may have, in healthcare, the biomedical clinical engineering organization has its own kind of asset database or, you know, spreadsheets that they maintain so you end up with not just different people with different functions but also very different systems that then get wildly out of sync.

And so one of the things that we’re really focused on is how do you provide a single source of truth? Just provide a data lake where you aggregate all the information that we know about these connected devices and then make it accessible to everybody and we can do that through our user interface and we build kind of a tailored user interface for different personas so you can have the biomedical engineer looking at exactly what she needs to know to do her job and that’s very different than the view and the information that the security analyst in the SOC needs to do their job. So it’s a common platform built on a data lake with different views but also integrating with the tools that each of these different constituents and stakeholders use in their day-to-day jobs, the way they manage their workflows.

So that’s the really critical thing is that we provide this data lake, this common set of information, so there’s a single source of truth that can then be fed out to all the other systems that are being used. And that is really kind of our function and that’s how you make astronomical progress as an organization when you’re breaking down those silos between organizations and you’re aggregating all of the data in one place and making it accessible to whoever needs it.

Erik: Okay, got you. Sounds fairly straightforward when you explain it right now. I imagine there are, in practice, a lot of challenges when it comes to actually implementing this, whether there are technical challenges of integrating these different systems or human challenges of getting people to buy in and provide information and, you know, I suppose there’s some tradeoffs, right? Potentially, when you start securing things in terms of having flexibility around how people want to use devices. What are the big challenges that you would typically, you know, address when you’re helping a company to onboard your software?

Greg: Absolutely. One of the real challenges that we focus on is making sure to get all of the different stakeholders together. So, very often, for our solution, the buyer is most commonly in the security organization but sometimes it’s led by the owner of the devices so manufacturing operations or biomedical in healthcare or the networking organization that’s trying to implement a segmentation process or even risk and compliance, the organization that is trying to make sure that they’ve got an enterprise-wide view of device-related risks. We’ve got multiple different stakeholders and that’s really kind of one of the key things is getting people on the same page, making sure that they understand that the right way to do this is not to have everybody have separate disparate systems that don’t talk, but to bring these, you know, a common platform.

And, very often, there’s a technology aspect to that but there’s also definitely people and process, making sure that all of the stakeholders understand, you know, what’s the benefit to them, how is a solution like this going to help them do their job better, more effectively, and how are they going to tie into and use this technology in their existing workflows, because no one wants to go in and reinvent how they do their job and what they do on a day-in, day-out basis simply because there’s a new technology being used.

So that kind of challenge, and this is very often where we work very closely with systems integrators and partners and consulting organizations that help organizations make these changes, not just implementing a technology but making sure that they’re implementing the organizational changes and processes that need to be put in place to be successful.

Erik: Yeah, so I can imagine the relationship with the system integrators and particularly probably very, very close, because they’ll often be the ones that are be implementing the solutions and making recommendations. What about the OEMs? What is the relationship? Because if I think about a company like Philips or Siemens, they have a lot of equipment in different facilities so they might have an interest themselves in securing at least their equipment, but then you may end up with a fragmented environment where some equipment has particular platform and other equipment outside of it. How do you work with the OEMs? Do they — I mean, are they customers of yours or are they always going to be viewed as a partner of some sort?

Greg: They can be customers and partners. You think about some of those organizations, you know, when you go into healthcare, you may find that the provider has their own private network that their equipment is installed on that, in some cases, OEM is responsible for maintaining and securing so they become, in that regard, kind of consumers and users of the technology so we can provide the insights of what the devices are doing and help implement security.

But they also become — we work very closely with them. We want to understand, you know, kind of, obviously, you know, we take all of the feeds of vulnerabilities and other information about devices from the manufacturers so we can make those available to customers. We can aggregate information so now once a manufacturer indicates that there is a vulnerability with one of their products, now the immediate question becomes for the healthcare provider, “How do I know which of my devices are impacted by that and what is the action that I should be able to take and how do I tie that and integrate that with my management, my incident management solution?” you know, so those ties, they are very, very important partners and they can be very good customers and users of our technology as well because they’re responsible for making sure that their devices and their networks are secured.

Erik: Okay, okay, great. Well, maybe we can look at one or two examples. If we have time, maybe we can look at one from the healthcare sector and one from the manufacturing sector and just do a quick walkthrough of what was the challenge, maybe what was the existing scenario that you walked into, who were you working with, how did you deploy, and just give us that kind of end to end perspective?

Greg: Yeah, absolutely. I can give you example of a healthcare provider so we work with providers, both very large systems as well as kind of smaller community hospitals so a broad range, but, you know, a very typical scenario is we come in, the organization has the realization that they don’t know what is connected in their environment so almost always that journey starts with, well, help us just get visibility and wrap our hands around what we’ve got, you know, so that we can make sure that our asset databases is up to speed.

You know, working with one of those providers, we very quickly helped them wrap their hands around the inventory of their medical devices but also all of their facilities devices, the other connected devices in the environment and we’re able to quickly show them which — and help them prioritize and understand which of those devices were of greatest value, greatest importance, and potentially most vulnerable, you know, so helped them with the risk prioritization. And in that case, they realized that they had several thousand devices that were connected to their network that were running Windows 7, and those were, obviously, a very old and, at this point, unsupported operating system and so they said, “Wow, these devices could be really vulnerable, but it would cost us literally tens of millions of dollars to replace all of those devices so what do we do?”

And we’re able to help them pinpoint exactly where these devices were and then to generate the policies which then got implemented through their network access control, NAC solution, to be able to lock those devices down and say, “Well, if I know that these Windows 7 devices are highly vulnerable, I really want to make sure that they are segmented and protected on my network and I strictly control what those devices can do and I control what outside systems have any ability to communicate with them.”

So it really became a very elegant process of moving from understanding the connected device environment, using that information to prioritize what devices were most vulnerable, and then implementing and working with their different providers and integrating with their network solution to ensure that those devices were protected. And so that’s — at scale, it was a huge implementation, but that’s a process that we go through with most of our healthcare customers.

Erik: And when you’re working with, I guess, I mean, you could be working with a department, you could be working with a hospital, you could be working with a provider that has multiple facilities, I suppose, to some extent, you’re probably working at different levels here but what is more common and are there tradeoffs? If you’re working with a department, do you have particular concerns around that as opposed to working across a healthcare network?

Greg: You know, very often, a conversation in healthcare may start with the medical devices. That’s kind of first and obvious. If there’s an infusion pump that is pumping drugs to my mother in the hospital, you want to make sure that that infusion pump is protected and is not vulnerable to attack. That’s kind of base and obvious and that’s where the concern always starts.

But then, very quickly, it tends to move to, “Wow, we’ve actually got all these other systems. What about all the printers and the video surveillance systems and physical security systems that we’ve got connected with our environment?” You know, those aren’t — you don’t have that same hair on the back of your neck reaction as the idea of malware infecting a medical device, but it can vary definitely once malware gets onto those devices, it can spread very quickly and affect the mission critical systems.

So, usually, it very often will start with a department within intents to broaden out as security organizations realize, you know, to protect anything, we really need to see everything, because it doesn’t do me any good to say all my medical devices were all locked down and protected but, you know, malware got into the environment through a connected television in one of the patient rooms and that’s how it got into the environment and spread. So you really need to cast a very wide aperture and see everything in the environment so that you understand where the greatest points of vulnerability and risk may be and they’re often not where you think they would be.

But you point to kind of also a very good question about, you know, large and very distributed environments and this is, you know, you asked also about manufacturing and, you know, that’s very often you see a central IT or security organization that may be responsible for maintaining and operating, you know, hundreds or even thousands of locations in places around the world and that’s where it’s really important. They don’t have IT staff, they don’t have people who are available to do manual inventories, so the only way that they can get a real understanding of what’s connected in their environments is through kind of automation, through using tools like Ordr.

And that’s one of the — when you look at some of those manufacturing or financial services, think about all the bank that are associated with a major system, you know, very often, small distributed environments with limited IT staff so what they really need is a system that gives them kind of a remote visibility and an understanding of exactly what’s connected in all of their environments and the ability to take actions to protect those and to respond when vulnerabilities are detected.

So, you see, healthcare is very commonly lots of relatively large implementations. You know, you get out into manufacturing and financial services, you tend to have very distributed networks with limited on-site IT staff and so the automation and the visibility it provides is really critical for those organizations.

Erik: Now, you mentioned earlier kind of briefly AI and so I guess if you’re looking at automation, you have more traditional automation model of having some rule-based system that you can roll out and, you know, if you’re confident in the rules, then it should work, but I suppose in some situations, you don’t know exactly what the rules should be around identifying risks and categorizing usage and so forth and so that’s where maybe AI steps in, but then are you in kind of a learning environment where you roll it out and you expect that, month after month, year after year, the system is going to improve its understanding of behavior? How does that automation of this process work?

Greg: It’s a great question. There definitely is a training process. When we install in an environment, we really need to learn, you know, first go in and classify all of the devices, you know, based on all of the work that we’ve done, the protocols that we parsed, the packet inspection so we classify the devices but also need to understand the local environment, the network to which they’re connected so you have that network context so now you can start to understand not just what the device is but how is it communicating and where is it communicating.

And that process of learning base classification can often be done in a matter of hours or days. You know, you train the system and it learns the network environment and gets better and better over time. And where the machine learning really kicks in is if you think about an enterprise environment that has hundreds of thousands of connected devices and thousands or tens of thousands of different device types, there’s no human being that can possibly track, you know, in their mind and understand, okay, exactly what and how does an infusion pump behave when it’s connected to our network. What about a printer or a Sony video surveillance camera or any other device?

The only way you can do this at scale is through machine learning. The good news is when we think about, you know, IoT devices and these unmanaged devices that we focus on, as we discussed earlier, they are kind of deterministic. They do the same thing over and over and over again and that gives you the ability to build a pretty accurate behavior model for that type of device, that profile of devices and that is what can be used to build out a really good security policy, because what you want to do is you want to understand what normal good behavior looks like so that you permit that. You don’t want to render a device inoperable or unusable because you’re blocking necessary communication. So you understand what good looks like and then you can use that to build out, say, okay, now I want to make sure — I want to limit this device and only allow it to do those good things.

And that’s ultimately the greatest and the best security that you can implement, because, now, you’ve really — if anything goes wrong, if malware gets into an environment, you can really restrict the blast radius because it becomes impossible for a device that has been very closely microsegmented, it becomes impossible for that device to communicate with other devices on the network and for malware to spread laterally and bring down not just one device or type of devices but to take down an entire environment or an entire enterprise.

Erik: Okay, okay. Very interesting. Greg, I think we’ve covered a good bit of territory here, but I guess from your perspective, we’re probably just scratching the surface of the topic. Are there any questions I should have asked you or anything else that you wanted to touch on?

Greg: No, I think it’s been a great conversation. I really appreciate it. And I think that the one thing that I really emphasize is that, you know, for your organizations, it can be a very daunting task. If you look at, you know, a large enterprise or even a medium enterprise, you have tens of thousands or hundreds of thousands of devices and a lot of them, you may not know what they are or what they do and it can be sometimes almost paralyzing, say, “Where do I start?”

And the answer is you really have to start with visibility. Wrap your hands, you know, basic hygiene, wrap your hands around the environment, understand what’s connected, understand how those devices behave and what vulnerabilities they have. That will be the key to enabling you to go in and prioritize risk assessment, because very few organizations are in a position where they wake up and say, “You know what, it’s mid-June, today is going to be zero trust day. I’m going to implement zero trust policies across all of my devices.”

It’s usually identifying which of my devices are the highest risk, most critical to my operation, let me roll out policy, let me protect those first, and then once I’ve done that, let me go back and get the next group of devices and the next group of devices. So this is not an event, it’s a process, and the way you work through that process is by having good visibility and a good understanding of the risk represented by devices so that you can prioritize and hit the most vulnerable devices, the most critical devices and make sure that they’re protected.

Erik: Great. Yeah. Great advice. Greg, if some of our listeners want to reach out to your team to have a deeper discussion, what’s the best way for them to do that?

Greg: Sure. They can find us just www.ordr.net and there’s a Contact Us button, we’re happy to have someone get in touch, you know, to show a demo of the solution and if it seems like it would be a fit, to put it in their hands and see if they can use it in their environment.

Erik: Great. Thank you, Greg.

Greg: All right, Super. Thank you so much. I really enjoyed the conversation today.