Erik: Welcome back to the IoT spotlight Podcast. I'm joined today by Sven Trekker. Sven is the chief architect of IoT Security Solutions with Intel. Sven, thanks so much for taking the time to talk to us today.

Sven: Hi, Erik, thanks for inviting me. Appreciate it.

Erik: Sven, in addition to, his work at Intel is also very involved in the industrial internet Consortium of the IIC. In particular, he's the cochair of the security working group. So today, we're going to be discussing the IIC’s security framework, which is a very well received document that covers the topic of securing IoT systems in quite a bit of depth. Sven, how long have you been involved with the IIC now?

Sven: Well, the IIC was formed in 2014 by the five founding members and has grown ever since. And I was actually there at the inaugural meeting. However, I certainly wasn't one of the chairs of the security working group. I think I was the chair of the vocabulary group, or something like that. So the good news is that we have a very strong vocabulary group as well, working with NIST. In fact, we're using we're sharing vocabulary with NIST. But then we transitioned on to the security working group.

And one thing I would like to add is the Industrial Internet Consortium was one of the early groups to have a top level security working group, which I think was a big element of the organization's ability to embrace security and really highlighted within IIoT.

Erik: Yeah, it was really a bit ahead of its game in terms of identifying the importance of security. I think this is well understood now. But maybe back in 2014, it was less of a priority as companies were just trying to get solutions out to the market.

Sven: It may reflect back on the nature of the five very large inter-multinational corporations that formed the Industrial Internet Consortium, that there was a concern that incomplete handling of security could certainly overturn the applecart. And I think five of those organizations were really all in on IIoT. And so they wanted to make sure they could assure the integrity and the opportunities that IIoT presented and to make sure they can be realized in a marketplace. And that really led to the incorporation of security at the top level.

I think it was one of the early indicators of what was to come. And I think, unfortunate, there will be quite a bit more to come and that's why we worked so hard to try to get ahead of that and make sure that the security is in place and that any negative impact would be greatly minimized, if at all possible.

Erik: But let's go first, a little bit more into the origins of this document. I think it's perhaps interesting for also our listeners to understand how the IIC gets in this case really more than a dozen contributors to collaborate and pool knowledge is extremely valuable, but not an easy thing to do. What did it look like, pulling together the contributors to this?

Sven: So fortunately, the Industrial Internet Consortium has 250+ member companies that contribute to the various activities within the IIC. So that includes business marketing, technology, security, it's liaisons, there's a vast set of activities going on within IIC, many of which I'm not aware of. But when we come down to security, the security working group is actually one of the largest groups within the IIC.

And when we decided to put together a Industrial Internet security framework, it really was a call to action. And I was very impressed by the level of cooperation and the willingness to step up and perform work in the form of writing and researching and editing that all of the member companies were willing to take on. And so it is become a very collaborative, our security working group, where in some cases we have direct competitors that are contributing to the same document. And I was really very impressed that a lot of the politics were left at the door.

And when we meet, we really focus on the problems at hand because it is industry problem and they cannot be solved by any one company. And so the competitive nature does tend to evaporate fairly quickly. And we focus on the bigger problems. And then of course, later when it comes to the competitive aspects, certainly they the member companies will then align themselves along there the battle fronts. But during the actual authoring of this document, there's really none of that. And I have to say I'm a member of quite a number of different consortia and standards committees. And that's rare. And so I really have to say this is a very, very strong group, not only from their security and technical background, but also of their willingness to do the right thing for the industry.

And at the time, the thing that we identified that was obviously lacking was some sort of what we call a security framework to tie together all of the industrial aspects and really highlight how it's different from traditional IT security and enterprise security and consumer security. And the industrial internet of things really has a much greater impact on our lives where there to be security issues. So, for example, it's not only the loss of revenue, and the loss of reputation, etc that comes with security issues in other domains.

But here we're talking cyber physical systems. And so the outcome of a cyberattack can have drastic impacts on human life and the environment for a long time to come. So, it really was a different level. And we took that quite seriously and really focused on putting together the thoughts of all of these 250 different member companies that come from different backgrounds and have different priorities. But to really put all that on paper and to think it through was quite a process.

And it wasn't always linear. So there were many times that we took four left turns and ended back at the place where we started. But now we understood the issue. And we’re assured that we were on the right track and that we were really putting together what was the right thing into the documents, which is, I suspect, one of the reasons why it really had such a positive reception. It took us 18 months and so we really did think through each and every elements of the document.

Erik: And the document it's very comprehensive. And if any of our listeners have not had browse through, I highly recommend it. I think, for many listeners, it might not make sense to do a thorough reading of the entire document. Who is the audience of this document? And then maybe on a broader level, how do you think about the question, who should know what? So within the organization going from certainly the IT team and then over to the BUs or engineers who are on the ground and then up into the mid-management in the executive, who needs to know what around security in order to make appropriate decisions at their level of decision making?

Sven: That's actually was one of the big challenges. And we sort of took a number of different directions before we settled on who really the audience is. And at the end of the day, we really decided that the audience includes really everyone. So it's the owners and operators of the industrial equipment, be that a utility or a factory or a hospital. But also, the systems integrators that put these systems together and the business decision makers and the architects and really, any stakeholder that has any kind of interest in a system should have some level of interest in the security and the related key system characteristics of that system. Because if you can't make the business decisions based on trustworthy data, then how could you have assurance that those business decisions are the right ones to be making?

So really, we see the security as being tied in not only to the technology side but really to the business side and the entire decision making process. So that really led us to put together a document that was designed for all different levels. And it really has several different parts. Maybe the first third of the document is really business perspective.

And it explains why you should care and what are the considerations, everything from classical risk analysis all the way out to new concepts such as trustworthiness where we talk about the security of the system not really being the primary focus, really it's about the safety and the reliability of these systems. And the security is there to assure the integrity of the safety systems and to ensure the reliability of the systems by building in resilience. And now coming up very quickly is the concerns around privacy. And so really, the security topic was central to those themes.

So we put those into very clear language and really describe what's important and why it's important and provide some background and the first third of the document or so. The second, third of the document is really more into the technical details, the implementations, the functional aspects, where we dig into the layers of the framework and what's important for the endpoints and the communications and the monitoring and the management and really a final chapter on what are all the things that we didn't even talk about, for example, fog computing.

There's a whole host of topics that we purposely did not touch on because there are other groups out there, there are other consortia and standards committees and thinkers of the world that are tackling those topics. And once those become ready, we will bring those into the document. And that really comprises that middle third.

And then the final third is really reference. So the reference materials that we got a discussion into the existing standards, we have some reference material for lookups into the topics and concepts that we provided. We have the index and the glossary. And so we really tried to make it a very complete document.

And for me, for example, when I pick up a book or pick up a document, I also don't read it cover to cover. That's really the painful way to understand anything. So generally, what I'll do is I'll look at the table of contents and then immediately flip to the index to see how well it's indexed because I need to find certain things and how well will I be able to find these things. And then I sort of flipped through it front to back and just look at the pictures.

And then whatever caught my fancy, I'll sort of spot read a little bit. And if there are certain elements that I need to understand better, I'll actually dig in. And then if it's a certain type of document, I will certainly doubt sit down and read it cover to cover, but only after I've done those other things and have sort of a flavor of the document and know where to look and so that I don't spend a massive amount of time understanding the structure of the document in the first chapter. I'll just skip that and go directly to the content and really trying to absorb the parts that are important.

So we tried to build the document with those aspects in mind so that the various different target audiences could very quickly get to the material that they found interesting and getting value out of it.

Erik: And I think particularly for this topic, where people are really trying to make a specific decision or inform themselves about a specific topic that's probably highly relevant to a business decision they make, that's the perfect structure. Let's dig a little bit more into this concept of trust worthiness. So this is a loaded concept that captures aspects of security, safety, reliability, resilience, privacy, and puts those to an extent into an umbrella. Is this a concept that's been around in the security community for a long time ago? Or was this developed by the IIC security working group?

Sven: Certainly, it didn't come from the security working group from the IIC. The concept of trust worthiness has been around for quite a while. In fact, there was some material very early on that really dealt with trustworthiness. The most relevant elements of trustworthiness that that we drew upon came from NIST and their cyber physical systems document, and that really got into the concept of trustworthiness that we felt were really compelling. We're really required for appropriately dealing with the topic of security in the industrial space.

And the idea there is that it is not really about security at the end of the day. If you go in and you deal with industrial system, everybody will nod their head fervently and say, yes, yes, we need to deal with the security of the systems. But then when it comes right down to it, that it leaves so much open, then it's not quite clear what has to be done. And often, what is done is insufficient; at best, often, there's nothing done and it's sort of pushed off to phase two of the project which never sees the light of day. It's always the next part of the project.

So, proper security is actually something that needs to be addressed in a way that's digestible, attainable, and understandable. So what we tried to do is really describe what the security is supposed to do. And the way that we did that is we compared this concept of trustworthiness, where we talk about the safety, reliability, resilience, security, privacy, and took that as a composite. And we say that in IT, traditionally, we talk about the privacy and the security and the reliability of those systems because they're financial systems, they're basically business systems. And there's some aspect of resilience in there. So certainly, safety is not one of the critical factors within the IT space.

Now, if you flip over to the other side, the traditional industrial operational spaces, where you're talking really about two things, it's really about the safety and it's really about the reliability. There will be some resilience in there because it assures both of those and there'll be some security because that enables it. But privacy, for example, is not on the radar for the OT folks for the most part.

So when we talk IIoT, it's really a convergence between IT and OT. And in many cases, that's actually something that's being resisted by the actual participants within those spaces. For example, in the OT side, it's very painful to bring IT solutions into an OT environment because the IT solutions were never meant to operate in an operational environment where if you get overzealous with the security rule and you block some activity, well, now the industrial process fails and can have dire consequences: things can blow up, can overheat, can melt down. That can't happen.

And so the operational world is very strict about manual overrides, about having access to any of the elements of the process and having the process completely air gapped and isolated from any kind of interference from the outside world. So as we start evolving over time and there's more smart capabilities, say something like predictive maintenance that provides a very measurable business value and the business wants to have that capability within their operational environment, well, how do you actually make something like that work?

So for predictive maintenance, there has to be some kind of communication of the sensor data out into some data bank that does the analytics and does the prediction of how these machines will be working in the future. So how do you do that in a secure way? Because by bringing the data out, that means that potentially other data, other traffic you can come back in; and if that's the case, that really wreaks havoc on operational environments.

So we came up with this concept of trustworthiness where in order to really consider security, we cannot consider security in isolation, but really have to consider it as one element of the five with the safety, reliability, resilience and privacy. And it's really a blend of all those concerns. And within each organizations, it will be a different blend of concerns and there'll be different systems and different standards and different capabilities that have to be considered. But it's never for the sake of security for the sake of security because that just leaves too much unanswered.

So by narrowing the scope down to supporting the traditional industrial concerns of safety and reliability as an example, the security controls there sort of materialize much more quickly. So for the safety systems, what kind of security capabilities are required to assure the integrity of the safety systems. And what do we need to do to ensure the reliability of the system? What threats are there and what security controls need to be put in place? So that's a much smaller constrained space where we're just considering two of those characteristics.

Now, we'd always have to expand out to the five characteristics. But it gives us a very good starting point. And it really, as an example, shows that it's a much smaller space where we can much more quickly come to a solution. And that solution actually has a demonstrable value, because there's certainly a value to insurance to assuring the safety of a system. But the reliability of the system, there's a financial aspect to that. And reliability engineering has a long, storied history and assuring those measurements and calculations are accurate is certainly within the purview of the security.

So it ties the security, especially the technical aspects, back to the business drivers. And just like the document, it really provides a very powerful lever to use within an organization explain why the security is important and gives you the first steps towards actually putting it all together. But not only does it talk about what those drivers are between the five key characteristics: the safety, reliability, resilience, security and privacy. But also, what they do? They have to resist the system faults and environmental disruptions and attacks and human errors. These are all real factors at play and they have to be defended against.

So how do you actually put that into practice? So our next challenge was in theory, we've got some leverage for the security. But how do we actually implement it? And it turns out in general, security is implemented by the operational users, the owner operators of the equipment of the systems. And that turned out not to be the best place to implement security because at that point, the system is already complete and you're essentially trying to bolt on the security after the fact.

So we started to look into how can this actually be done correctly? So in order to build trustworthiness, we need to have what we call a permeation of trust. So the trust needs to permeate throughout the entire landscape and even lifecycle of the systems. So from the operational users’ perspective, rather than trying to solve security problems, they should be providing system requirements down to their system builders, which can be systems integrators or service providers or what have you. And they in turn, would take those requirements and push them down to the component builders who are the hardware vendors, the software vendors, the OEMs, ODMs, etc, that put these things together.

So by pushing these requirements all the way down to the lowest levels and coming from Intel really understanding that it has to come from the silicon at some point, the more security capabilities that can be locked down in silicon to prevents eavesdropping, tapping and violation of integrity, etc, the better. So you actually seeing a lot of the semiconductor folks pushing more of the security capabilities down in there. For example, a lot of people are talking about the hardware root of trust.

And there's an entire industry around building trusted execution environments where a hardware root of trust can be anchored in order to assure everything from the boot of the device on up. And without that, it's actually very difficult to ever measure the effectiveness of the security because you can never trust the measurements. But having that hardware level security up, you can bootstrap each step along the way and provide those measurements and have a way to assess authoritatively the effectiveness of the security.

And so if each of the component builders from the silicon on up to the force of the devices, comes together and provides that functionality that security function mountains functionality according to the requirements. Then when it goes back up the stack from the component builders back up to the system builders and systems integrators and service providers, they have the tools, they have the hooks that they need to implement the security and be able to report out on the level of security.

And then all of that is bundled together into a system provided to the operational users and now the operational users, the owner operators of the equipment, they actually have tools that enable them to measure the trustworthiness of these systems all the way down to the silicon, all the way out to the data and know that the decisions have a way to evaluate the level of trustworthiness and trust within that data that they should have when making business decisions.

So really, it all comes full circle, where if we can build at the lowest levels, the security capabilities and evolve them up through the process until finally the operational user has the tools needed in order to assure that level of trustworthiness, that really leads us to a place where the security as part of that trustworthiness can actually be assured. And I think that's really the vision that we're trying to paint with the industrial Internet and IIC is trying to bring that into reality.

And it's interesting because the document that we wrote here really spells out what's important, what kind of considerations should be in place, and how to assure those. But we also have testbeds. And so what we do is we sort of “eat our own dog food”. So we prescribe the security considerations, and then we have additional documentation, for example, best practices, we have published the endpoint best practices based on standards in a number of the verticals. And we tie that back to the ISF, Industrial Internet Security framework and so we show how it really can be applied to the standards.

And then we take all of that is that we also have the maturity model, we have a security maturity model, spearheaded by Microsoft, similar to their Stripe model that we're developing for the industry where you can actually measure the maturity of a solution, both in a running system, but also even at design time to measure how mature the system would be, to build out a roadmap for how to evolve that security over time to fully realize a mature and secure system.

So we take all of that and we implement that within the testbeds of the IIC. And we have a number of vertical testbeds. We have some horizontal test beds. There's quite a variety of test beds available in the IIC. And we really have security playing a central role in there. It's part of the process of approving a testbed and part of the recurring process for the continued efficacy of the testbeds.

So we really make sure that it's not just things we talk about, we actually do these things. And we take those findings and we come back and work them back into the ISF. And you mentioned earlier that it is an evolving document, it's an evolving space. Security is not a product. It's really a process and process changes over time. So we're actually planning to have a number of revisions here. We have a minor revision that does a little bit of refactoring and moving elements around to have them make a little bit more sense in the flow of the document, if you will read it in one sitting.

And then we have a larger refactoring where we want to come in and provide a little bit even more of the perspectives. So in addition to the technical perspective and the business perspective, we'll have a couple of other perspectives that we add in there to further clarify the security, why it's important and what to do. So there will be a number of updates to the document, both major and minor coming out, we'll need to figure out the exact timeframe for that. And going forward, this is going to be a living document that evolves as the industry evolves.

Erik: These testbeds are not security tests, but these are approaching real security practical but really end user issues. So we're talking about connected care, connected vehicle, factory automation, digital solar plant, intelligent urban water supply, precision crop management, smart airline, baggage management.

Sven, you outline the best practice, when you to an extent have the luxury of building from the ground up, which is something we should be striving for. And in some cases, if we're talking about self-driving vehicles or something because the technology is really emerging now, we have that luxury to an extent of really thinking through how we can secure these from the silicon up. In other cases, and I'm thinking here around brownfield deployments in OT environments where the equipment might be 10, 20, 30, 40 years old, what are the specific challenges that you would face in enabling trustworthiness in this system?

And is there a set of similar best practices for brownfield environment where a significant proportion of the asset is going to be quite old with quite limited capability and you have then this messy also operational environment where it might be difficult to implement the ideal architecture that you would ideally like to implement and you have to work more with snap on solutions and really a lot of workarounds to achieve a particular goal?

Sven: Yeah, so. So that's a tricky situation. And it actually does occur fairly often in a number of the industrial verticals. So in order to address that, we need to sort of take a step back and see where all of the security threats really lie. So to begin with, there are challenges within the hardware, the processor, the memory, the peripherals, etc. And then there's the convergence into the firmware, the UEFI BIOS, all of the boot steps, we then have operating system level issues or [inaudible 47:11]. In certain endpoints, we have hypervisor issues that need to be dealt with. Sometimes there's actually no OS at all, it's just a bare metal application embedded. So there's the application layer that sits on top of the operating system sometimes that's sitting in a virtual instance or sometimes it's in say, a software container like Linux containers or docker or something like that. All that is really within that deployment environment.

And so having a real level of control over the trustworthiness of that deployment environment becomes key. But it's really not just in the endpoint. It's not just in the endpoint. So there's also the data that flows through the endpoint and knowing how to monitor and to analyze that data and the monitoring and analysis themselves. So it's not just the data that's in motion and in use and at rest. It's also about the analytics that are running. In addition to that, how do you configure and manage these things? And how do you protect them from being misconfigured and mismanaged? And what is the security model and the policy.

And all the way back to who actually designed this thing, and were there errors or time bombs built into this back in the development phase? So, all of that has to be really considered. And when you consider that for a legacy environment really where the data communication securing it was not a high priority at least and the endpoint security capabilities are generally quite immature, it becomes quite challenging, especially when you start to mix new devices with old devices; so for that as the greenfield and the brownfield, the brownfield being the legacy devices and then the greenfield devices being the new devices.

So what we're looking for there is a way to implement security. And ideally, we need a way to implement security immediately in a brownfield legacy environment. And one way to do that is to rip everything out and replace it. But that's not a very good way. It's expensive. It's risky. It's generally not what's done. It's generally a no go. So instead, what we can do is lay out some essentially build a secured layer over the top of the existing process. And so what we can do there is put in place some gateways, for instance, in front of the devices and the systems and those gateways would actually represent those systems on the network.

So from the network perspective, you think you're talking to say an electrical breaker and the breaker is telling you that everything's okay. But you're really not talking to the electrical breaker at all. You're talking to a gateway that is representing that electrical breaker on the network and it is actually looking at the network traffic that's passing through and deciding is this something that matches the policy for what this breaker is supposed to be doing. So as long as it's talking to a PLC or to an HMI or probably talking to a PLC, all that traffic is passed through. But if you plug in your laptop onto the network, and you try to communicate with this breaker, it will say, well, I don't know who you are and I won't communicate with you.

So it takes an old electrical breaker that really has two physical phases, on and obviously, you either flip it up or you flip it down. And at some point, somebody thought it would be a good idea to be able to remote control that thing. And on that day, a cable was plugged into it and you're able to send it commands, that changed everything, because now it is a connected device and IIoT is all about connected devices.

So protecting connected devices with a gateway, it would be a first step. And what that provides is from the gateway on behalf of the device, a machine identity for machine to machine communication, or even cloud to machine or machine to cloud or what have you. And then that identity is leveraged for mutual authentication between all the different gateways and as you bring on new devices, they can usually authenticate those new devices.

The point is that these legacy devices that had no concept of the security constructs can be made to look like they have identity, can usually authenticate, can authorize traffic, can implement the security functions of integrity and confidentiality on top of the existing networks by leveraging the old legacy protocols but simply tunneling them through newer more security aware structures. So you need to translate to new, more secure protocols and then translate the back to the legacy protocols on the other end, or you can just create an encrypted tunnel and just pump that legacy data right on through there to the other side.

It's a fairly good solution. It's fairly inexpensive. It's fairly quick to roll out. It doesn't solve all the problems though. Because if you have physical access to the equipment, all you need to do is unplug the gateway and plug your own thing in and the device, in this case in our example, it was a breaker, it's still the same dumb breaker, it doesn't know anything. So there's still a vulnerability there. But what it provides you with is an immediate step up in security. So you have a new floor, new worst possible security scenario because you've rolled out the gateways everywhere. And now everything has an identity and can be authoritatively identified and they can mutually authenticate. And that adds a lot of value to the overall security capabilities.

And in addition to the security, they're also now remotely manageable. So a management instance can configure the gateways to update security algorithms, the tunnels, the allowed firewall rules, the deep packet inspection signatures, whatever is needed in there. So these things are updatable. And so now you have a more future proof solution. And when quantum computing comes around in 10 years, was 20 years ago, whenever it comes around, it'll surely get here. So whenever it arrives, we'll be able to have an update capability to refresh all the algorithms for something that's quantum resistant.

And while you're at it, you can also monitor from the security perspective what all these devices are doing. So it's very difficult to interrogate a breaker and understand its security posture. But if you put a gateway in front of it, you can say, hey, I've had the following data pass through that I fully expect. But here's a set of events that I didn't expect. These may not be of interest to you, here they are. And then you pump that through analytics and then you get overview of what what's really happening from the security side.

And does that lead to artificial intelligence, monitoring industrial systems? I don't know. I could certainly see that it may in the future. But all these things become possible. With today's technology, with today's existing infrastructure, by applying adaption techniques such as laying out these gateways in front of a legacy equipment and then as new equipment is added to the environment, as long as it has those features, identity, authentication, authorization, etc, they should fit seamlessly into this model and allow a roadmap going forward so that the industries can actually start replacing equipment at a rate that is feasible for them. It's not rip and replace all at once. It's over time with a controlled evolution, where the security is intact each step along the way.

So it sounds excellent. It's actually more complicated than that. But from the basic idea, that's the conceptual approach to it. And it certainly is something that can be achieved. It probably requires some coordination between the standards organizations to really lay out how do these things work? How do they communicate with each other? Let's figure out a way that they can be consistent across the board. And if we can do that, then we actually have a very powerful, and very future proof security solution that the industry can rely on going forward. So that's the vision of where we think this may be going.

Erik: I think gateways also help to address one of these other constant pains in the industrial IOT space which is connectivity across different protocols. So you're also maybe addressing a couple of problems with this approach that you've outlined there. But one last topic that I think would be interesting to have your opinion on is you've outlined here both for greenfield and brownfield environment a best path forward, where are we today in terms of being able to implement these options cost effectively more or less plug and play or at least conveniently without a lot of customized work from whoever's owning the system? Can you give us as of June 2018 where are we today viewpoint?

Sven: So where are we today? Well, we are in an environment where finally there is a heightened awareness for security and the criticality of security within the industrial space because of the industrial Internet. So I think that's the first step. That’s the longest time we had a hard time taking. There were other priorities, the rate of technology, evolution was so great that that's all we focused on. But here comes the complexity that comes along with that. And then we very quickly realized that the security is required in order to keep all of that in balance. So we've taken that first step.

So now what do we need to do? In order to realize a world like we just described there where there is a standardized approach to security and organizations can evolve over time with the knowledge that there's this compatibility layer, and even in the post quantum world, there are solutions that will be solutions, presumably in place at that time, which can then simply be updated. And just the update and upgrade process is somehow addressed. I think we have line of sight to that.

We still have to sit down with the standards organizations and really understand how these things should work and what specific steps need to be taken. And then after that, you dig down into the interfaces and how to make it all interoperable. And then you got to go to all of the different vendors and say we realize you all have your own way to do it, but here is a way that the industry has decided would be the proper way to do that from that industry's perspective.

And then it's a matter of adoption. And there are a couple of different drivers to adoption. So for example, one lever that would certainly create a very quick security adoption were if software liability were pushed through, and it's really a situation where any damage that you caused from your hardware or software would be your responsibility, which today is not the case. So in that case, there would be an immediate response to security. However, it would probably greatly stifle innovation because now everybody's in an environment where they're afraid to make changes and to innovate and evolve. So that would be a way to do it, maybe not the best way.

Another way to do it would be through legislation. And we're seeing a lot of that across the world right now, especially around privacy. So there is legislation that describe exactly what the privacy rights and requirements are for various industries. And so something similar could be done for security. And that would certainly cause a very quick shift to a more security aware environment. The downside of that is much of that depends on the security savvy of the folks drafting the material. It depends on the intestinal fortitude of the politicians that are trying to push it through.

And honestly, it depends on the exceptions and the waivers that are built into it, and how much bite does it really have. If it's more cost affordable to pay the fine than it is to secure the system, then it was really offered nothing. And really, at the end of the day, we're talking about the trustworthiness of the system, not just the security. So that's a way to do it. And we are certainly seeing some of that. But by far, we think the best way is to go through the standardization route, where the industry itself agrees on what should be done and gets it done and implement it.

So that's where we are today is in an environment where we've taken that first step and had the realization of the importance of the security and the trustworthiness and we've started to make strides to improve it. Now, we just need to get to that standardization phase where we can all agree on how it should work, and then put a roadmap in place to ensure that over time it actually does work that way, and that there is evolutionary path to get us to a place where the security is assured.

Because if you think about it, this is the fourth industrial revolution, and each industrial revolution has preceded the previous one much more quickly than the last. So the rate of industrial revolutions is increasing drastically. And along with each industrial revolution, the complexity goes up drastically. So those two together give you sort of the hockey stick curve, where the complexity goes off the chart very quickly and the industrial revolutions start going more and more quickly.

So as we start getting closer to a phase where, within the next 25 years, these industrial revolutions are going one right behind the other, how do we support an environment like that and assure the security or the trustworthiness of that kind of environment? If a major security breach can black out the United States potentially forever, that's certainly a major consideration.

If there's a way to drastically interfere with the ability to do business by bringing down Wall Street or by any number of different scenarios contaminating the water supply or what have you, that's something that needs to be guarded against and just ensuring that there's some kind of a framework in place that can provide the security foundations so that we can evolve security over time is critical. And now that we've embarked on that, and we're making strides for it, I think we do have line of sight for a bright, happy future. And so, compared to where we were in 2014, I think things are looking a lot better. So, if I had to roll it all up, that's where I think we are right now.

Erik: And very much thanks to the contributors of this document, I think the companies behind this really are pushing the market forward here. I think Google is intending next year to have a fleet of self-driving cars out I forget if it was in Denver or some city in the US. And certainly, had IoT One, we've been seeing a big uptick in terms of projects moving from pilot phase towards real world deployment. So it's to an extent a race between you and the people that are trying to build business models and figuring out that there might actually be some early mover advantage in getting really robust solutions deployed. Sven, any last points that you wanted to touch on before we call it a day.

Sven: Well, you bring up the automotive space and automotive is certainly one of the big drivers for IIoT at the moment. There's electrification. There's connected vehicle. There's autonomous driving. So there are a lot of changes going on simultaneously in that space. And in the IIC, we just spun up two new task groups. One of them is the automotive task group and one of them is the automotive security task group, both of which are looking at this space and looking at creating some testbeds and providing papers on that particular vertical in particular.

So, as there are changes in the industries, we will certainly adjust and track those and collaborate and help in any way that we can. So, we see this as the beginning of our adventure, not as the end. So, we're in it for the long haul and look to support it going forward.

Erik: We're now having industry-oriented security task groups. This is at least a strong sign that there is really a lot of focus on security right now. So this is a nice evolution over the past several years. Sven, thank you so much for taking the time to walk through with us today. We'll share the security framework in the show notes. What's the best way to learn more about the work that you guys are doing and to get in touch if somebody wants more information, maybe it's Kathy, or what would be the preferred mode there?

Sven: Yeah, so reach out to the IIC. It's iiconsortium.org, iiconsortium.org. And there's a lot of material, all the papers are out there, and they're free, of course. You don't have to register for anything and get spam mail for it. So simply reach out, let them know that you're interested in security, or whatever it is that you're interested in and they'll get back to you and start sharing information. And that's really what it is. It's a collaborative consortium of assuring the ongoing prosperity of the industrial Internet. And we welcome everybody.

Erik: Well, Sven, thanks so much, and I'll bid you a good evening.

Sven: Thank you, Erik. I appreciate the time with you.