Adopting Zero Trust
Adopting Zero Trust
Adopting Zero Trust with Ryan Alford: IoT Secured

Adopting Zero Trust with Ryan Alford: IoT Secured

This week we chat with Ryan Alford, Founder and CEO of Engineering Design Group (EDG), and we dig into how Zero Trust impacts the future of hardware, software, IoT, and access (both human and machine)

Catch this episode on YouTube, Apple, Spotify, or Amazon.

This week we chat with Ryan Alford, Founder and CEO of Engineering Design Group (EDG), and we dig into how Zero Trust impacts hardware, software, IoT, and access (both human and machine).

As a hardware manufacturer that provides software connected to critical data sets, they have a double edge sword to consider when securing their products. On one end, they must ensure their devices can’t be tapped into (such as ensuring physical ports can’t be exploited by plugging in a device like a thumb drive), and on the software side, addressing risks ranging from access, to the supply chain, and data security.

Removing Implicit Trust and Securing Access

In modern cloud-based organizations, there is no perimeter or metaphoric moat around the castle. One of the most critical areas of Zero Trust, and where most organizations accept implicit trust, is through how people and devices access resources and applications. 

Does a full-time employee need access to all services on your network? Is a simple username and password sufficient, even if communication is encrypted through a VPN? 

Least privilege access is a core aspect of Zero Trust, and essentially means a human or device functions on a need-to-know basis. Today, this can be as simple as role-based access (RBAC) such as Bob the engineer needing access to his DevOps apps and a database, but Jane the CTO has increased visibility and the ability to grant and restrict access to the systems.

“The whole idea is if, if you bring on an employee or a team member or a contractor who's working on just one, one project, they don't need access to all of your projects. They don't need access to your entire code base. Uh, they probably don't need access to your networking infrastructure. They don't need access to all of your passwords.”

Unfortunately, this is not granular enough because it does not consider limiting access to certain monitored/controlled devices, locations, etc. These software-defined perimeters (SDP) begin to blur the line when you add in granular access controls.

Certain identity providers (IdPs) expand upon role-based access and least privilege access for more granular control, but this is usually where a solution like Zero Trust Network Access (ZTNA) fills in the gaps. There also happens to be a significant amount of overlap between the concepts of SDP and ZTNA. If you want to go further down the technology rabbit hole, ZTNA is often part of SASE (Secure Access Service Edge), but that is a conversation for a later date and that is mostly aimed at enterprise organizations (AKA companies with $$$) and include a lot of bells and whistles that not every company needs.

Principle of Least Privilege (Least Privilege Access)

As a quick aside, Least Privilege Access or the principle of least privilege has been around long before the concept of Zero Trust exploded:

“In information security, computer science, and other fields, the principle of least privilege (PoLP), also known as the principle of minimal privilege or the principle of least authority, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.”

Back to Ryan and EDG’s scenario, which raised an important point for why they are taking a Zero Trust approach to securing their hardware and cloud-based software.

“We talked about the repositories and all of that and limiting access. But when, when you start to have hardware accessing databases, and users accessing databases, there's also a level with the technology where you don't want to just trust your devices or trust your users.”

For Ryan, this means authenticating everything and ensuring only the right people and devices/hardware can access data based on requirements. More specifically, treating hardware like people and building personas and roles for mapping.

But before any access is granted, Ryan builds security into the contractor and supply chain onboarding process. While this may seem like table stakes, for a younger company, following compliance-driven processes and building controls is often driven by outside factors like customer requests rather than by their own planning. However, for Ryan, he stressed the importance of a security-driven approach in order to establish trust with their customer’s data. Like people and processes, Ryan applies the same thinking to their hardware.

Securing Hardware Through Simplicity

In the past, hardware was typically handed off to the purchasing party and they would manage configuration, including ports and default passwords; however, that flow has time and time again proven to be a well-known attack vector when not implemented correctly and widens your attack surface.

“So what we try to do is make the best choice on behalf of the user. All they have to do is plug in the device. We ship 'em the device, all they have to do is apply power, and they log into an app, and everything else in the background just magically happens.”

No network config, password setup, or other manual adjustments are required. It’s just plug n’ play. For Ryan, applying Zero Trust to hardware can be as simple as reducing configuration requirements for the end user.

However, are a standard set of granular access controls sufficient? What happens when you bring into the equation devices on the move? Geofencing is great for stationary devices and equipment, but regardless of satellite or cellular connection, there are plenty of mobile use cases.

In order for geofencing to work in this scenario, the device and person need a routine to establish a fingerprint; otherwise, something like machine learning or AI would be the required baseline to effectively implement secure access at a Zero Trust level. Today, this level of technological fingerprinting isn’t quite a reality, which is all the more reason why it’s important to remove all aspects of implicit trust.

“From the hardware side, not trusting that our own hardware is secure, you know, somebody can and will hack into it. This happens to every company and every company who says, you know, our devices are 100% secure, probably just doesn't understand security, you know?”

Like Ryan’s own hardware and software, he took us back to a time when he was considering adding a third-party sensor to EDG’s hardware. During security and compliance due diligence, things went a bit south.

“It was kind of just like, oh, don't worry, it's secure.”

Clearly, that statement didn’t hold merit, and Ryan dug deeper asking if the vendor worked with any external pen testers, had third-party validation or audits, or reports that detailed what they are doing from a security perspective.

“There's always more that companies can be doing. We're developers, we're engineers, we're big on testing. We're big on automated testing, but we're also big on cross-testing and having other people. If one person writes the code, have somebody else on the team review the code and test it. But hiring external test parties and external penetration testers, I think there's so much value in that because they have their hands on other products so their experiences are going to be not nearly as narrow-minded as the teams who are designing the product where you have tunnel vision.”

Building Trust Through Transparency

To wrap things up, Neal asked Ryan where he feels organizations can get started with adopting Zero Trust; he pointed us towards passwords and access management. In many cases, IdP and multifactor come up frequently as starting points, but even before that, password management is just as crucial. By creating unique passwords, never reusing them, and storing them in a safe vault, you’ll reduce the potential impact in the event of a single system getting breached. More importantly than technology, though, is treating Zero Trust as a cultural mindset.

Zero Trust in itself is not all about technology or how you rework your architecture; it’s about building trust with customers and your ecosystem. If you treat your strategy as having a baseline of zero, this applies to the public, your supply chain, employees, and everyone in between. For Ryan, he likens this to how everyone has some form of privacy policy listed on their site but feels the bare minimum should be around transparency. That is to say, he feels that every company should have their form of a vulnerability disclosure policy, plan, and way for others to contact you about flagged items.

Takeaways from Ryan

  • Access by contractors and third-party vendors should be highly limited, which is why solutions like VPNs do not align with Zero Trust

  • Through an Identity Provider (IdP) such as Okta, Microsoft, Apple, etc. you can limit access by the user to specific cloud-based apps, but these solutions may not support 100% of your items out of the box (may need custom builds via API integrations).

  • From hardware to software, it should be assumed that nothing is fully secure and that runs under the scope that you already have been infiltrated. 

  • There are no silver bullets in security. Always verify, especially security claims, and lean on  third-party validators (pen testing, security or privacy compliance, etc.)

  • Being transparent and honest is one of the best ways to build trust. Ryan suggests having a continuity plan that includes a vulnerability disclosure plan and a way for people to report issues.

Coming Up Next

Next week is our off week, so we won’t air a new episode; however, the week after we have a big name in the world of federal DevOps and Zero Trust, Nic Chaillan.

Nic Chaillan [LinkedIn] [YouTube Channel]

Nic is your resident DevSecOps, Zero Trust, and policy thought leader who just happens to have been the first U.S. Air Force and Space Force Chief Software Officer (CSO). We chatted about policy, bringing Zero Trust to the federal space, the challenges that come from digital transformation (read: getting buy-in is always difficult), and all of the amazing resources he offers on his site and show.

Adopting Zero Trust Episode Transcript

Elliot: Hello, and thank you for joining us today, today. We have a fantastic guest Mr. Ryan actually, you know, I'm terrible with giving introductions based on our guest. I would just actually love if you can give us a little bit of background and then we'll we'll go into the spiel from.

Ryan Alford: Yeah. So my name's Ryan Alfred I'm founder of a company called engineering design group. We also like to call it EDG or edge. We've been in operation for about two years. We design. Hardware, mobile apps, web apps, and the entire cloud infrastructure in between. And yeah, I'm here to talk to you guys about security and really happy for the opportunity.

Elliot: Oh, if we are more than happy that you're here. I think one of the store points that Neil and I have actually not run into is that there is a huge hardware element for cybersecurity and zero trust in particular. But most people beyond the concept of devices, it's not even on the table, it's completely missed out of a lot of the frameworks.

I think maybe they'll do light touches, but for most people they probably consume it is cloud driven elements, which obviously there's aspects of what you do. And we can kinda get into that in a. But I think you're gonna be able to bring a flavor of this conversation that we just have not been able to reach yet.

This will definitely be highly enlightening and I'm sure our folks at home are gonna be thrilled to be able to kinda get that insight, especially for other startups and organizations who are trying to build in the hardware space and trying to meet with these current modern demands as well. Cool. Yeah. Sorry Neil, go do your thing. I always interrupt you.

Neal: No, you're good. I was just gonna say walking, aboard Ryan. I usually let Elliot maybe preposition the room a little bit with the first question or two, and then we can take off and come back to him towards the end.

Elliot: yeah, there you go. I usually chime in with the stupid comments somewhere in there, but yeah, , I'm just check.

Neal: he's

Elliot: So

Neal: you to know. He just wants to keep you off guard until he really lays it on us. Both.

Elliot: might be the case. We'll see. So that being said. Usually we do kind of throw out some basic questions, but I'd love some insight into what you are building today. And where zero trust falls within that scope.

Ryan Alford: Yeah. Where, where we got really acquainted with zero trust was really when we started to work with bringing on employees and contractors and, and interns and that sort of thing. And, and, you know, we started talking about zero trust and, you know, the concept of zero trust as you guys know is basically never trust, always verify.

On, on the company organization level for us, that really meant limiting who has access to what right. You know, at, at, at a very, at a very minimal you know, whether it's passwords for our infrastructure whether it's GitHub repositories for things we're building And these sort of things.

The whole idea is if, if you bring on an employee or a team member or a contractor who's working on just one, one project, they don't need access to all of your projects. They don't need access to your entire code base. They probably don't need access to your networking infrastructure. They don't need access to all of your passwords.

So that was really where we started to implement zero trust, right from the get go you know, using a password manager to help with all of this. And, and from there, it kind of just became one of, one of the core elements to how we operate. And on the, on, on the product side, you know, we, we do develop hardware, software, cloud infrastructure.

So there's, there's a lot of pieces compared to. Some other tech organizations, you know, a lot of organizations will just have maybe the mobile app will be their focus point or maybe the cloud and databases will be their focus point or, or they're just creating hardware. So we, we also really needed to, to think about this in how we're building our product.

And you know, we, we talked about the repositories and all of that and limiting, limiting access. But when, when you start to have hardware accessing databases and, and users accessing databases there, there's also a level with the technology where you, you, you don't want to just trust your devices or trust your users.

You need, you need everything to authenticate and. Really what's, what's, what's interesting on the hardware side that, that I think is really important is treating hardware, treating the devices, IOT devices as actual users. And once you start to look at them as users it, it can really simplify the product design.

It can simplify the organization and, and the same types of zero trust concepts that you apply to users can also then be applied to those devices.

Elliot: so you are speaking to the choir on this. I lived and breathed zero trust accessibility. And I I've made a note to Neil about this quite a bit, because obviously in the past there were things like putting a DMZ in place, which reduces some access, but most organizations still today rely on VPN access.

And that as, as much as certain companies will say, and they say that somehow it aligns with zero trust. It still involves a level of implicit trust. That just gives too much. But yeah, without a doubt, obviously there's software defined perimeters or SDP. There's now zero trust network access, ORs, DTNA.

I'm just curious, and I love the contractor use case because that is always like the easiest entry point for having that conversation about granular access controls and giving just the right amount. Cuz obviously if they only need access to one database or one resource, you know, how are you looking at a situation like that where you only want to give them access like that?

What are you trying to put in place to, I guess, prevent opening the or putting the moat down for the castle.

Ryan Alford: Well, a lot of times, you know, if we are working with a contractor, it, it starts with really kind of that initial conversation with them where we're. We're we're effectively interviewing the contractor that we wanna hire for their capabilities. But you know, if, if, if, if they're sitting down and telling us about their organization usually usually groups that are mindful of security issues are gonna bring those up when you're hiring them.

And they're, they're gonna be eager to tell you about all of the things they're doing to protect your repository, protect your data not put app secrets in the repository and those sort of things. And if they're not talking about that, you know, for us, that's kind of become just the first red flag, you know, and well, if, if they're not talking about it, you're gonna ask them about it.

Hey, you know, what are you doing? What are you doing to, to prevent issues? Who's working on this? You know, what is your vetting process for your team members and that sort of thing. And, and it, it, for us, it it's actually felt like a pretty natural part of the process. When we're, when we're vetting when we're vetting contractors.

Now I, I obviously all startups kind of do things differently and you know, we, we've had some really good luck with contractors and we've had some, some experiences that were not ideal as well. And you know, as, as we're growing as an organization, we're finding that you know, it's, it's actually better for numerous reasons to keep our technology under our roof.

Right. You know, it, it eliminates that question of who's gonna do what with our intellectual property. You know, you can sign as many agreements as you want, but if somebody's out there if an employee of a contractor is fired and they have a copy of your, of, of a repository on their laptop, Well, you know, what can you do, right?

You know, unless the laptop is a company owned laptop. So by, by bringing technology into the company and taking it away from the contractors you become a more secure organization, but, but there's also the benefit of that knowhow is inside of your organization. So when issues come up and they always do, you're not gonna have to rely on the contractors to bail you out.

Neal: So I'm gonna personally, backstep slightly on something you said a minute ago, I've got my handy daddy note taking devices. So I can remember to ask certain things that peak my mind and still pay attention. That being said, you know, getting started, you mentioned you know, getting to a methodology around finally treating the devices as if there were persona right.

More implicitly, you know, we tend to put our in a standard it frame of reference, you know, we tend to do a pretty decent job at a, at a good org, gets saying, you know, device a talk to device B, and that's what it should be. Now. We don't necessarily do a good job monitoring when it starts talking to device C however, right.

When someone comes in and pivots through, but I think in a control systems world, this is one should happen a little bit more exclusively. And two it's probably also a lot harder to do as people are still mapping. Old school, OT to new school, I O T concepts. Right. So kind of curious in that frame of reference where you see a potential breakdown between 20 year old tech stack and trying to make sure that something can't pivot through those doors versus modern tech stack, that might be able to take advantage of more common practice sense stuff, where there might actually be a legit IDs inside the control system, right.

Or some version within the historian or some control groupings, right. For that implicit. So just kind of curious your take on old school versus new school and treating the device as a person in that rationale and making sure you don't completely crash something.

Ryan Alford: Yeah, that's a great question. Let me, let me kind of start with the problem that we're trying to solve with our product and, and we can kind of dig in from there. And, and if, if I, if I take a meandering path just, just feel free to steer me. Our goal, our goal is really to allow our customers to, to monitor their data and own their data and, and get the raw data from any number of devices in the world that are connected to the internet, whether that be through wifi cellular or satellite technologies, get that data to their fingertips in a reliable and secure fashion.

To do that, you know, it's very easy to have an app talk to a small handful of devices, right. But what tends to happen when companies are, are scaling up IOT, they gonna, they're gonna start with a small number of devices at first to prove that you're the vendor that they wanna work. Okay. They may purchase five or 10 or 20.

They're gonna put those on a handful of networks maybe one network depending upon their application. And they're gonna use use this, use a mobile app or a web app with a, a combination of users to access those devices. once that initial deployment is successful the hope is that company is gonna grow right.

If they have a retrofit solution, if you're retrofitting a non-connected solution or, or some kind of a legacy solution they're gonna be quickly ramping up the number of devices that they're working with and the number of users. When you go from just five or 25 devices to a hundred or 500 or a thousand there's, there's, there's a lot of special things that, that need to happen to be ready for that.

Right. Making sure that, that, that the channels are big enough for the data, making sure that multiple simultaneous accesses are not are not interrupting each other. Right. So we achieve that with our cloud infrastructure. Okay. In, in, in our platform, there is, there's no way for a user to access a device or for a device to send data to the user without passing through our cloud infrastructure.

So that's really where you know, the, the, the API that, that we've developed that allows users to access data. And that allows, that allows, allows our devices to receive commands and, and. Submit data to the cloud. That API is really kind of the first level of protection and all of the encryption and tokens and verification that has to happen there for authentication.

That's really the first level of protection. So back to your question, which I think was how is this different than, than the old way of doing things? And my belief is at least what I've seen in my, in my career, which is, you know, limited to my world view historically devices required a very large amount of configuration by the user, right.

So the user had to know. You know how to set up IP addresses, how to set up ports, right? Default passwords, which we, which we hate. Right. You know, every, every device of this model number shipped with the same exact password, and now it, it, it, it shows up out on the, out on the internet and that becomes an attack target for everybody today.

So part of how we handle that is you know, as, as you guys know reducing the surface area available for an attack. What we try to do is make the best choice on behalf of the user. So all they have to do is plug in the device. You know, we ship 'em the device, all they have to do is apply power and they log into an app and everything else in the background just magically happens.

Right? They're not, they're not going in there configuring passwords setting up. You know, setting up networks and, and this complicated stuff. So that to me is really something that can be done today. And, and we're starting to see more and more companies heading this direction that I think is gonna improve. You know, when, when we look back in 10 years, we're gonna say, you know what, this worked a lot better than the way we did things 20 years ago, because there was less configuration.

Neal: I, I take my brain out into the left field a lot. I used to do. Loosely termed exploitation and, and worked on like physical hardware security on embedded systems for all of like maybe a year and a half, two years. One of those things like, Hey, who wants to go to black hat and learn how to poke and prod things with some diodes?

I'm like, sure, send me that being said, I, I love the concept of, especially with any device, any security device, the, the fundamental idea of geofencing something you know, if we think about it's a server and you've got it locked down the way you should, and there's zero trusts mentality that only things from this region, this construct all this, that first entry point barrier to entry, unless they somehow manage to go through the backside is always gonna be from something not within your spectral area, right.

Unless they happen to go to your house and actually go through your system, which is possible. I, I just, I dunno, the idea with geofencing for IOT makes even more sense, cuz most of these are some kind of nowadays some kind of cell phone and able type device that inherently has a GPS chip somewhere in the solution.

Ryan Alford: And one, one thing, that's one thing that's really interesting about, about that comment. You're, you're absolutely right. You know, we're seeing more and more devices make it into rural applications and, and we're still in this shift of everybody Mo transitioning over to cellular. But you know, O on, on our side, you know, so we're, we're. We're not just in the consumer space, we're also in, in a high reliability space. When you talk about high reliability, you, you start talking sometimes about defense contractors sometimes about energy infrastructure. You know, thinking back to the, the colonial pipeline incident, right. You know, cellular devices are, are not gonna be enough.

There's gonna be cellular devices, but there's gonna, you know, pretty soon everybody's gonna be facing out cellular for satellite. Right. And, and there's, there's gonna continue to be a need for this geofencing. And you know, when we, when we think about the, you know, all of the worry and, and scares of the transition to 5g and how is this gonna work and what's gonna be around, what's not gonna be around anymore.

Nobody's really having that conversation of well, You know, how, how do we need to behave differently once everything's on these satellite networks? Right. And, and I think, I think, you know, engineers, you know, I, I, I see a lot of engineers that are really excited about these devices. I'm excited about them.

You know, I have some eval boards coming in that I'm, I'm really eager to play with, but I, I think we need to start looking at that and saying, wait a minute, this is, this is something we need to look at and, and really really consider what are the pros and cons of this service, cuz you know, at, at the surface level, satellite sounds really good, but you know, I think we need to pick it apart and analyze what are, what are some possible consequences of going to satellite versus cellular for IOT?

Neal: yeah. On, on that note, I mean, that, that's a wonderful point. It's kind of funny, you know, the sooner we get tech now, obviously the sooner we face things out as things get exponentially. Growth, all, some other stuff on that note from a satcoms perspective, I am happy to report that there is an ISAC out there that is very worried about this idea.

The downside is here in the states, right? We don't yet consider space infrastructure, a oddly enough, a critical asset, key resource, critical infrastructure, oddly enough, you know, it's considered a, a support element to other things still to this day. But obviously if you took down satcoms you took down, you know, some kind of earth station, something like that.

There's so many things that are gonna go away very, very quickly. Heaven forbid you just take out GPS on things and that really mucks everything up, right. Especially at these remote stations that rely on that for tokenization and, and passing off timing that being. Space ISAC just to plug someone that I'm very familiar with highly encouraged looking into that endeavor.

And you know, if you have a really good personal preference into that side of the house and, and getting involved as it seems like you might hit them up, they're there in Colorado Springs. And on, on a side note, I'm also happy to make intros into that world too. I, I love the, is a and the ISOs.

It's one of my personal things that I like to work in and then help do things with, for collaboration, information sharing but your, your back on track, your concerns about that are being directly echoed by this new community. So larger companies that are board members of this company have taken notice that the government seems to kind of push them off to the side.

Now they're putting on this big major focus and there's this huge growth effort over the last roughly now almost two years. To build something around the satellite community. Satcoms infrastructure up there everything from rocket launches, physical all the way down to the data layer digital and everything.

Ryan Alford: Well, the, it, it, one of the other things that, that this conversation brings to mind is when, when we got our you know, we got our router, we started up the organization, we got a router, had to get some equipment online. And you know, I hadn't bought a router in 10 years and it has it has a, it has a backup for cellular, you know, so if your wifi goes out, you can still have, you can still, still have an internet connection to the office.

And I think you know, I O T devices Talking about the transition to satellite, it's it, it may not be a transition. It may be satellite satellite with cellular backup, depending upon the location. Right. And, and, you know, a lot of when we talk about devices a lot of IOT devices are, are being used for asset trackers or, or like fleet management.

So these are things that are going in and out of regions that have coverage. And, and you know, maybe there's some parallels there where depending upon, you know, if, if you have the option for both cellular and satellite, what is more secure for that application and why? Right. And what's, what's going to keep.

The device connected in times of need versus you know, which, which of those networks is more likely to have a hiccup for, for whatever reason.

Neal: Yeah, I think that's, that's something else. I always forget about the trucks with their GPS monitoring and location tracking, all those other fun things. That's a whole nother Bailey wick of funness, and that throws geofencing potentially out the door for that particular asset, Ryan, they can have their laptop and everything running through whatever com system they've got in there.

And, you know, they can drive from Cali to Alaska in, in two weeks. Right. But when you think about concepts for me, the the need for zero trust from an IOT device, or, you know, pick a flavor of whatever it may be an RTU I E D whatever it is, those end units that that's where the end goal is a lot for some of the potential threat actors is to get onto that end device to open up a switch or to close the switch, whatever they want to do.

But at the end of the day, you know, whether they're exposed to the internet or not, if you make sure it's talking to this device and only this device, and then to your products point, this device inherently is also managed through another product solution to make sure all this is managed correctly.

And that's the only trust line. And it's that consolidation of monitoring effort, which in most OT networks doesn't really happen very well. From what I've seen, everything's just floating around, out there. Maybe it's behind some kind of historian or Mt, whatever it may be for the sake of the human in the loop.

But once you're in there, you are literally in there in a lot of these networks, I think that's what kind of freaks me out a little bit. You have to get there still, and that, that is thankfully, still very hard part of the puzzle, but.

Ryan Alford: Well, well then I, I think what you're talking about, I, I think what you're, what you may be alluding to here is Hey, you go out in the field. You, you wanna hack into some computer system. Oh, there's a USB port on it. I'm I'm gonna plug into this. Right. And you know, there's this is another element that's interesting on the hardware side is there's, there's, I'm in a group hardware into kind of two sets.

Okay. And, and there, somebody else would yell at me for this, but there there's, there's two sets there's there's what I would call cots devices, commercial off the shelf. Right. So that, that would be oh, you know, we don't have time to design something. We're gonna go buy this embedded X 86 PC from this company, because it has, you you know, the latest Intel core processor that we need.

It's rated for minus 40 to plus 85 Celsius operation. They've designed it as an off the shelf product. I can order it. It'll be here in two weeks. Right. When you're buying a product like that, where you're putting on the operating system and you're developing thet hardware All of the connections, you know, the, the, the, the product is gonna have a lot of peripheral connections available to it.

You know, it may have cereal ports, parallel ports probably not parallel unless you're like really, really old school legacy embedded stuff. You know, ethernet, USB, what have you all of those things are gonna be exposed. So when the user gets that product and puts their, their software on it, they can use it in whatever way they need.

Well, there's gonna be a limit there. There's likely gonna be a limit to what the user who's putting the software on it, what they can button down. Right. It's gonna be limited to the operating system and their software, you know, you know, whereas the vendor who's supplying that cots product, you know, if that's running if that's a, like an actual embedded computer running a bias, That bio has the capability to really lock things down in a different way, at a lower level.

That's gonna completely turn off connectors and not expose them in the address space, for example. Right. Well, well, so we have this one category of devices, cots devices, and, and that could include raspberry pies or Doos, anything where you get the product and everything's turned on, and then you also have this, this custom tailored world of hardware.

And, and, and that, that also kind of enters EDG. We're kind of straddling that space now because we have, we have created standard products, but we can figure them uniquely to our customer applications. And what's really nice about that is we can turn off we can turn off things fully at a lower level when they're not being used.

Right. And okay. Yes. If somebody hijacks our firmware, can they turn it on? There's probably some way to do that, that we haven't uncovered yet. But for instance, you know, if we have a product that, you know if, if you had a product that uses a Bluetooth for, for commissioning that device and, and connecting that device to a wifi network is that Bluetooth on, is it left on 24 hours a day or when they turn on the mobile app to, to punch in the password, does Bluetooth turn on only on an as needed basis and then the vendor turns it off.

And, and this is where I think the zero trust element really comes into play with, with customized hardware that is designed for a specific application. And that's, that's where I think. There's a difference. And, and part of the difference is you can buy the raspberry pie. You can buy the off the shelf, embedded PC and get up and running quickly.

But, but you're not gonna have the same level of security granularity that you would. If you are designing a customized solution from the bottom up, or you're working with a vendor, who's designing a custom solution for you from the bottom up.

Neal: So I'd say it's nice to know that in control systems unique customizations and, and kind of DIYing it based off what you want is still a good is still a thing. Old school, you know, when you get a Siemens product pick. Pick a step seven product back in the day, no matter where you're at, I buy it, you buy it and they buy it.

And everybody's ladder logic and programming structure within it is all completely different. Right? Security through OBS security. I think that's a 1 0 1 thing for most control. I know it's actually still a thing. I, I honestly think that's a good thing. I think unique customizations around certain aspects are inherent to what's needed, but also a good way to mitigate commonplace faults where you know, just because you know, that there's vulnerability and pick a SERE or whatever product or whatever it may be nowadays.

I'm a little behind on the brands that are out there, but doesn't mean you're gonna actually use it on target a when you found it in target B, even if it's actually readily available, cuz hopefully they maybe turn it off. Anyway, that being said when we start thinking about deployment operations and, and putting these devices, do you think from an it to OT perspective nowadays, do you think it's.

Based off of what that network is supposed to be doing. Do you think it's easier to do the right thing to lock down an OT world, comparatively to an it world from a zero trust mentality, at least at like the core end device. So coming back up to the top of that, where, you know, treat a device like a person?

Ryan Alford: Right. 

Neal: you know, an endpoint device should really only ever probably really talk to one other thing, right. It maybe couple, depending on the engineering, what kind of accesses they're going through, but it sounds like with y'all the idea is to provide that central focal point for log management.

Perhaps if I, if I'm understanding right.

Ryan Alford: right. Yeah, it it's, it's not just for log management. You know, the log management is important for, for debugging purposes and for security purposes. It, the central point is, you know, what can I say, how, how do I say this? It's the logical way to design a platform for distributed systems. And it comes with it, it, it lends itself to security in some ways, right now you have to design in various things, right? It's not just gonna be secure, but there, there is an inherent nature to security when you're using you know, when you're, when you're not allowing devices to, to, to interact with each other directly. But I, I think you're, you're still gonna have that.

We haven't quite gotten into that area. You know, we, we we've had. Customers that have asked us, you know, where, where, okay, we have this one device that needs to talk to these, these other things that are local to that device, you know, I guess, I guess that would be in the realm of edge, edge compute.

Right. But we, we haven't actually our company hasn't, hasn't actually implemented anything in that way yet.

Neal: Yeah, I think the one concern I probably have with I don't know if ZigBee's still a thing or not. Maybe it is Power infrastructure at the neighborhood level, back in the day, relied on, maybe it still does Zigby for the new, the new meters and the lights and everything to really tell, but it's a full mesh topology kind of concept, but it was it was an implicit trust model.

So if you could get into the system one way or another and understand what formatting they were using for traffic, and you could get into the system and collect a lot of fun things,

Ryan Alford: Oh, wow.

Neal: And it, you know, it's inherent to any communication structure. It ran off of the same bandwidth as 8 0 2 11.

I'm gonna get it wrong. G I think, I don't remember but anyway, long and short different protocol standard for coms, but there was this implicit trust when you set it out because it was supposed to be a closed network, but you stick up an antenna and if you can take enough pack of cash and understand what it is you're looking at, congratulations.

Most of that stuff wasn't very well encrypted, or if you get access to someone's meter, And by proxy, you know, they can talk to any other meter on the network because they gotta pass billing data down this mesh to eventually whoever's collecting it in the billing system. So I guess that's something that I'm thinking about from a worrisome perspective is, and it sounds like we're moving at least from your realm of what you're working with.

They're, they're moving away from maybe the core competency of that loosely, hopefully, and moving towards more of like back to that centralized piece.

Ryan Alford: Yeah, it, it's hard to say. I, I think it's gonna be application specific and, and, you know, some of the areas that we're trying to get into right now, which are you know, more in the, the oil and gas and energy space we're, we're, we're we've recognized that there's already some IOT infrastructure in place, right?

You know, when we're, when we're trying to solve one of their problems and we say, Hey, we've got a product for that. You know, there's gonna be this push pool of well, Well, we've already got our network. We want your device married to that because we already have this point, that's communicating up to the cloud and, you know, again, it comes down to convenience time, money, and okay.

You know, what are the consequences of that? And, and, and, and is the, the owner of that application will willing to live with those consequences. Right. So we're gonna have to deal with this pretty soon. You know, we're gonna be dealing with this this year, some of these questions if I may, there was, there was something I wanted to talk about that kind of I think also lends itself to zero trust and, and you know, there's always this trade off of, you know, how much data are we sending?

What's it gonna cost us, right? What's what's our monthly cost per device. And one thing that. That we've been noticing is, oh geez, our, our costs are higher than we thought they were gonna be. And the reason that is, is, is, you know, as a small company, we've, we've been segmenting our customers to, to, to use.

We actually have several, we have unique instances of our infrastructure for each customer. And, and our philosophy behind that was, Hey, if, if, if you know, these are slightly different app applications running on the same infrastructure, different data sets, different numbers of systems. If we have one customer's application goes down, you know, if something were to happen, the other customers don't suffer, right.

Those continue to run. But similarly we've also done this for the security side, right? It, it, it, it keeps, you know, it, if. If somehow somewhere were, were someone were to get into our system or, or get onto one device, they're not gonna be able to hijack our entire customer base. Right. Because these things are segmented.

Well, that is a higher cost to it. Right. You know, you're, you're running more app instances. You, you have a lot more things to manage. So what we've started to look at and, and, you know, what, what virtually every, every SAS company does is there's different pricing tiers, right. So we're what, we're, what we're gonna be doing for our entry level tier is, is everybody's bundled in on the same, on the same system.

Right. And this is where you know, I, I think, I think from the user standpoint, you know, what our experiences with customers is, is again, We wanna buy, we wanna buy a device. We want you to ship it to us. We're gonna plug it in. We need to access it. If it works, it works. That's all we care about. Nobody.

Nobody is out there scrutinizing, Hey, well, okay. What's the difference? You know, what do we really get with your enterprise plan? And, and you know, I, I, and I think this comes back to you know, we're here to serve our customers and, and, and that means steering them in the right direction. That is best for them, even if they don't know that.

Right. And, and having those conversations and, and having those discovery conversations about what they're doing to really say, listen, we need you on this tier because your application is doing something very sensitive. It's gonna cost you more money, but let us explain to you what. What you're what's gonna happen here that's different than, than this lower pricing tier.

Right. You know, again from the hardware side not trusting that our own hardware is secure, you know, somebody can and will hack into it. This happens to every company and every company who says, you know, our devices are 100% secure, probably just doesn't understand security, you know?

And, and, you know, you, you do everything you can, it's, it's a defensive thing. You, you, you, you follow, you know, you, you patch things, you send over the updates to your devices. You watch the news and, and you get the reports and, and you, you plug the holes in this ship before there are holes, I guess.

Right. But inevitably As we learned, I think two or three years ago in the X 86 world specter and meltdown. I don't, I don't know if you guys, if, if you heard those words in your circles, but what they, they uncovered that, you know, every, every X 86 system going back, like 20 years had these vulnerabilities and the only way to patch it was with a bios update.

Right. Mm-hmm well, so how many of those systems are, are, are, you know, running you know, clean water for municipalities today that don't have the bios update, right? It's, it's not so much the security, you know, we're, we're not so much worried about what's gonna be exposed today, but the, the nature of O T is you know, you know, millions of devices getting put into the world every day, every week and the growing number of the devices.

Well, What about the devices that just get put out into the world and then the company sees us to exist and there's no more updates and, and customers, you know, they have, you know, you have all these consumers with these IOT door locks and IOT window locks, and, and one day they're just not gonna be supported.

So what, you just throw all that away and you, and you go install a bunch of new ones. So again, I, I think all I'm saying is that things there will become a time where the technologies of today will be able to be hacked. You know, we're gonna be at a different place five years from now, 10 years from now.

And you know, we need to do what we can, as soon as we can to, to defend those devices.

Elliot: I think you incidentally opened my favorite can of worms, which is the concept and definition of zero trust. Because if you look at it maybe from the vendor side, not as much, cuz I feel like they're being a little bit more intelligent about it now. But silver bullets, as far as security technology definitely used to be a thing.

But zero trust definitely puts, gets put very high up on a pedestal as far. How secure that concept and following it to a T will basically enable you to prevent breaches and elements like that. So I fully appreciate the realist view, which is somehow somewhere internally, externally, there's going to be an entry point regardless of the you know, adoption, zero trust or specific technology elements such as that.

But yeah, that is.

Ryan Alford: was, there was a sensor manufacturer a couple but ago that I was, I was talking to you know, we were. We're gonna be evaluating their sensor and, and, you know, we're, we're putting it on our platform, but they had their own platform and you know, of course I asked, well, okay, you know, what are you doing to secure your platform?

And it was kind of just oh, don't worry, it's secure. And it's well, you know, don't give me that, you know? Okay. Okay. So what are you doing? You know, are you working with an external pen testing group to, to, to verify that, you know, can you send me a report? You know, what are you doing? And, and you know, I, I think there's lots of there.

There's always more that companies can be doing, you know, and, and, you know, we, we are big, you know, okay. We're developers, we're engineers, we're big on testing. We're big on automated testing, but we're also big on cross testing and having other people, you know, if one person writes the code, having somebody else on the team, review the code, test it But, but hiring external test parties and, and external penetration testers I think there's so much value in that because they have their hands on other products.

So their, their experiences are, are gonna be not nearly as narrow minded as, as you know, the, the teams who are designing the product where you're, you have tunnel vision. You're just like, okay, we have to ship, we have to ship, we have to ship, you know? And I think that's, that's a very delicate balance that a young startup company has to deal with is meeting deadlines.

But also, you know, is the product secure, you know? And, and, and I don't think there's a right answer for what that balance is. But continuous improvement. Is something that all companies can and, and should be working towards.

Neal: Yeah, I think that's a wonderful point and device security is a lot more than just making sure an IP address can't get to it. you know, it's a lot more robust requirements around that. And the last little piece for me, you mentioned earlier on about, you know, the physical access perspectives of this, right?

So right down to the whole thing, if you don't have a robust security posture for physical digital and, and everything else that goes in between, just because I can't log on from IP address a, B or C doesn't mean that I'm not gonna find something else. If it's still dangling out there on the Internet's in front of other stuff, right?

At some point in time, you will find that hole you will get in. And there's a lot of other things that go into that mitigation strategy to make sure that that one hole is not as impactful downstream for.

Ryan Alford: Yep.

Elliot: Yeah, totally agree. And I think actually, Ryan, you, and I kinda discussed this before. I know it's future state and basically product holes into what you do with pen testing and activity like that, but finding those proactive elements that really just allow you as you know, your own worst enemy allows you to kind of crack open the system to the best that they can.

Ryan Alford: couple other things that I, I just wanted to throw out there before we're done is, you know, zero trust. It, it doesn't have to be an expensive thing for companies to implement it. This is, it's a cultural mindset, right? And, and I think once, once you have a coup once you're called once your, once your culture has adopted that mindset it, it becomes baked into your, your daily habits and, and how you operate.

But similarly one, one last point I really wanted to talk about was vulnerability, disclosure policies VDP, and, and this is something we encountered this within the last six months. I think the group is called the T security foundation. And I was talking with them and, and I read this article, oh, you need a VDP.

I was like, well, what, what is this? And, and vulnera vulnerability, disclosure policy, this is another small shift you can make in your organization. And, and, and it's really coming up with a, a, a, a short, simple easy to digest document that is public that tells, tells your customers here's how we handle security vulnerabilities.

And, and it, it does a coup it, it, it does a couple things. First anyone who does find a bug, it, it gives them a dedicated channel to reach you. And, and but probably more importantly, Is, is it communicates, Hey, you know, we're, we're not gonna point fingers at you. If you find this bug you know, we're gonna, we're gonna need to look at it.

It's gonna take us 48 hours, then we're gonna respond to you. And, and it kind of, you know, what, what you don't want is for somebody to find a bug. And for some reason, feel like they can't report that to you. You wanna know about it. And, and so having some kind of a web contact form or an email dedicated to this with a public public facing policy it, it, it kind of says, Hey, you know, here's the type of company we are.

We want to talk openly about this with you. We, we, we, we if you find something we hope you'll, you'll talk to us about that. And I have not looked for any company that's had, that's had one of these, but I've never, you know, What was the privacy policies, right? Suddenly in the last, all of a sudden every company had a privacy policy and you go to their webpage and it's boom, in your face privacy policy.

Well, you know, I, I hope there comes a time where for T companies we're gonna see, oh, privacy policy, vulnerability, disclosure policy, right? Because these are things that you know, companies should be educated on. We should, we should, we should, we should know that these exist. We, we should, you know, put the link in the bottom of your webpage, wherever.

Maybe it doesn't need to be a popup, but you know, if, if you're in the business oft you, you are in the business of security, whether you like it or not.

Elliot: I com I love that take, I mean, what you basically hit on is building an establishing trust in a zero trust world. You know, when you start a baseline at zero, how are you able to do that with customers and people that are connected to your devices and software? So being able to have that level of transparency and communication that is not something that a lot of organizations are probably comfortable doing.

So being forward thinking and kind of build that into your culture. I mean the only thing that I could figure would be that is a, an step towards establishing trust. And just not a lot of organizations are comfortable with it.

Ryan Alford: you know, and you know, we're, we're a young company we're small. And we, we hope to grow in, in, you know, part of our strategy is, is really people aren't gonna buy us stuff unless they know how we operate. Right. And educating customers on proper practices, whether whether, whether those practices are security related or not, whether maybe, maybe it's Hey, Here's how you wanna wire your system to make sure that, that you're not getting noisy data.

Right. But educating your customer on these types of practices it, it, it builds it builds trust, like you said, and, and really, you know, you know, we want to be there when, when somebody, when somebody's comparing and con contrasting companies, Hey, who are we gonna buy this device from? We want them to say, well, you know, we, we read that one article from EDG and they taught us, they taught us about, you know, this particular feature.

And we really like that. We're gonna buy from EDG. Right. And you know, again, these are all they're they're tools to improve security, but they're also tools that will actually help move your company forward.

Neal: day one. Hmm. We did this, the last call too day one, if you had to pick something on the zero trust concept to start off with whether that's research, which everybody hopefully is looking to do that too, but whether it's learning or implementation focused either either side of the spectrum, what is day one for you, for people kind of just diving into this really about or could

Ryan Alford: I would, I would say low hanging fruit go down, you know, implement a password manager and, and create, you know, vaults or areas in that password manager that, that limit what users, what, what your team members can access re restrict their passwords on an as needed basis. It it's a, it, if you're a small organization, that's a really quick thing to do.

And, and it doesn't cost a lot of money. So that would be that I think that's a great introduction to understand how zero trust works.

Elliot: Actually. Thank you so much for your insight. I appreciate that we able to do a bit of a deep dive between the hardware and then some of the lighter touches, which is more friendly to my education. I'm just kidding. Yeah. Again, just thank you so much for your insight. I think this has been incredibly interesting.

A lot of people beyond the devices, just at the basic level and user touchpoints, don't really look at the concepts of zero trust involved. But I feel like as we kind of build this conversation you know, we'll be able to point to this conversation and be like, Hey, this is exactly the kind of concepts that we need to look at being fully transparent taking into consideration policy and documentation and what elements that those are gonna play in the future as zero trust.

Thank you so much for being able to be part of that conversation.

Neal: Yeah, Ryan, thanks for putting up with. Ignorant questions. Like I said, I, I have weird ones, but every once in a while they come back around to good things. So thank you for, for following along with me a

Ryan Alford: I certainly have some homework on some acronyms to do when I get outta here. No, I, I really enjoyed talking with, with you Neil and Elliot. Thanks for the opportunity to talk about zero trust in security in the IOT space. I had a lot of fun.

Elliot: Excellent. Well, thank you all so much and thank you for listening. We will see y'all next time.

Adopting Zero Trust
Adopting Zero Trust
Today, Zero Trust is a fuzzy term with more than a dozen different definitions. Any initial search for Zero Trust leads people to stumble upon technology associated with the concept, but this gives people the wrong impression and sets them off on the wrong foot in their adoption journey. Zero Trust is a concept and framework, not technology.
We are on a mission to give a stronger voice to practitioners and others who have been in these shoes, have begun adopting or implementing a Zero Trust strategy, and to share their experience and insight with peers while not influenced by vendor hype.