 The panel is having so much fun. I almost didn't want to break it up with them, but thank you very much for coming to CSIS. My name is Jim Lewis. I'll be moderating this event, which is entitled Enabling the Internet of Things. And so we have a really strong panel. One of the reasons we're doing this project here at CSIS is in thinking about, you know, every year we try and think, what should we be looking at? And we realized probably last year that the Internet is changing radically as new technologies and new software change how people will interact with it and how machines will interact with each other, how people interact with machines. So the Internet's going to be very different in a few years. It's already on the path to that. The Internet of Things is part of that, right? You always get some number when you go to these events, how there's a zillion, you know, in 20 years there'll be a zillion or 50 billion or something. It doesn't matter. There are already more devices than people on the Internet, right? It's about twice as many devices as the entire population of the world. So there'll be profound social, political, and economic effects. And what we've been thinking about, and the panel will touch on this, you know, a set of problems. First problem for us is how do we extract the full economic benefit from this change, right? And this is something that I've been thinking about since I first learned unwillingly to program a computer, which is, wow, this software stuff, it could really make things easier. How do we get the full economic benefit? Second, how do we not get in the way of innovation? And that's always a big temptation. If you think back to the start of the Internet, we didn't regulate it. We didn't have a lot of rules. We kind of let things happen in the large part because we didn't know where the market was going to take us. It gives a little more credit to the people who did it in having foresight than is really fair. But you don't want to make assumptions about what are the things people and companies will choose to use and then regulate based on that. That would be what I'd call the European error. Another problem is what do we do with all the data, right? We already know that there's more data than people can deal with. There are technologies to deal with that data, to make use of it. Data aggregation is an important part of the Internet business model. How the Internet of Things and the data it generates fits into that is something we'll have to think about, right? One of the things I think my sort of initial thinking on this is all data does not have the same value. And so sometimes you see privacy schemes that say anything generated by a machine that a person owns is also personal PII. I don't think that's necessarily right. I don't really care if you know what my car's tire pressures are or something. And you can really get yourself into some fun knots. I've been asking European officials if my cookie, if my refrigerator uses cookies, will it have to notify me? And their answer has been yes, right? So we want to think carefully about how we treat data. One size does not fit all, right? And finally, a bit of science fiction. The panel doesn't have to talk about this, but in looking down the road, how are we going to interface with the Internet of Things, right? How is it that we will, you know, I like to at least see them where they had the jack in the back of your head. That's probably not going to happen, but it could. How will we interface? And my bet here initially is it will probably be some more powerful kind of something like Siri, you know, a vocal command, but it may not be. We don't know. Looking down the road, we have a lot of issues before us, but even more issues, we have a lot of opportunity. So that's kind of why we're doing this. Let me introduce the panel in the order I have them. Matt Scholl is the Deputy Division Chief NIST, Computer Science Division. He promotes strong cybersecurity practices, metrics, known not a while. So we're very grateful that he's willing to come and speak. Hillary Kain, the Director of Technology and Innovation Policy at Toyota, has been at Toyota now for about two years. Before that was on the Hill, did a lot with the Committee on Science, Space and Technology and was a staff director, pardon me, for the Committee on Technology. And really some interesting things to say about what Toyota is doing. Smart Car is one of the favorite iterations of Internet of Things. So I'm looking forward to your remarks. Mark Ryland, Chief Solutions Architect, Worldwide Public Sector, Amazon Web Services. That's a great title. He leads the people who think about the solutions that Amazon will use. He's an evangelist. He does architecture for both government and private sector customers. So, Mark, thank you for coming. And finally, Jeff Green, the Director of Government Affairs for North America. And Senior Policy Council. Okay, good. I thought my title was bad. But Jeff, many of us know Jeff, of course, from his time on the Hill. But he did escape and go to Symantec. Symantec is the sponsor of this project and this event. So we're grateful to them. Jeff comes out of a background of Homeland Security and Cyber Security. And I think some of our panelists will be able to speak a little bit. I don't know if it's Matt or if it's Jeff on what the end stack has been doing recently and thinking about the Internet of Things. So I've talked about as much as I should. Why don't we just go down the row and have each of the panelists talk, and then we'll open it up for questions. So Matt, do you want to start? Thanks, Jim. So my name's Matt Scholl. I'm from the National Institute of Standards and Technology, an agency, a technology agency under the U.S. Department of Commerce. And we are one of the many, both U.S. government organizations and organizations kind of worldwide that are conducting research development and looking at different technological needs that need to be developed, understood, or standardized in order to fully realize some of the points that Jim talked about around the Internet of Things, the economic benefits, fostering innovation, and then understanding and deriving the knowledge that we need from these large data sets that are going to be generated from the Internet of Things. As a technology organization, NIST is really focused on standards, measures, metrics, and the technologies that are needed in order to allow for this to occur. We are an agency under the U.S. Department of Commerce. So as such, we are really focused on the economics and the innovation and how this can be used to assist and spurn new growth in U.S. industries. We are very interested in the standardization requirements, as well as the underlying measures, metrics, and needs that are needed here. So when we look at the Internet of Things from our perspective, we look at it holistically through the entire architecture of it. And right now, there's a lot of work, and we're kind of in this standard scrum going on right now where we've got both Laserdiscs, Betamax, VHS, Blu-rays, and DVDs all being developed at the same time around what is and what are the standards to be used under the Internet of Things. So it's going to take some while before this standardization around allowing full scope of interoperability and interface settles out. And in the meantime, our role is to work with U.S. industry in those standards bodies and advance those interests where we can in order to accelerate the use of adoption of this. So we look at the Internet of Things from a very low-level perspective, all the way up through the back end. So from the very low-level perspective, these are devices that at their hearts are sensors, usually system-on-chip size sensors, very small, very lightweight, very inexpensive, usually hardware-based, and the interfaces and the ownership, as Jim mentioned, will probably come at the virtualization stack or at the application interface where they can be controlled or where the data can be gathered from. And then from those very small, very distributed system-on-chip sensors, as NIST were very interested in, what are the calibration requirements needed for these sensors? And that can vary wildly. So your NIST thermostat probably needs a different error rate than the sensors that are going into an aluminum manufacturing fab for temperature control. And then what are the calibration needs on these systems on chips so that good decisions can be made on the data that's derived from them? And then what are the data standards that are needed in order to transmit what those calibration issues are as well as the data that's being generated from the physical environments that these sensor systems on chips are generating? Then from the system on the chip, from the sensor that's generating data off the physical world, there's a need to transmit that data so these sensors will most likely be wireless in some aspect. The data needs to get off the sensor and then back to an analytic engine or somewhere where there's either an algorithmic expression or a knowledge derivative analytic engine that'll drive knowledge and allow us to make decision based on policy from the data that's being generated. And then there's a feedback loop. So that was a very fancy and geeky way of saying, my fridge will tell me when I'm low on peanut butter if I told it I care about peanut butter because I have a peanut butter policy. And then based on that policy, I will be alerted by the sensor which drives data from that physical infrastructure and then that'll derive an action which will be me buying more peanut butter, okay? That's just a very simplistic example but this can explode out into many other different use cases which scale for efficiencies, economies, understanding, conservation of resources. And there's many different areas where this is being used to great advantage. Some of the areas are in preventive maintenance. So if any, I was on an airplane this morning from Huntsville, Alabama, my aircraft and my airframe has multiple sensors on it driving physical data off that airframe and that airframe performance, everything from oil pressure, oil temperature, speed, vibration and that's all being pumped into a backend cloud so that rather than waiting for scheduled quarterly maintenance on the aircraft, if something seems or starts to look out of place, the airframe manufacturers can ground it and conduct effective preventive maintenance and do it with a knowledge base that conserves the time of the repair people as well as the resources that go into it all the way through to smart agriculture which is the other widely discussed use case where we can apply water or pesticides or fertilizer to the spot plant rather than applying to fields overall, conserves resources, reduces pollution, much cheaper overall and yields greater yield. So those are just some examples of how we look at it. We have concerns about system on chip design, where how are these things fail, understanding of the data, what are the data calibration requirement needs, what are the data interoperability standards, what are the communication protocols needs to derive and pull the data off the sensor, what are the security requirements that are needed across that stack, what are the machine to machine identity requirements that are needed, how do you control them, do we have enough pipe to move all this data around and then how do we apply understanding of the error conditions when you do those analytics on that back end to derive knowledge, what are my error bars and do they aggregate. So these are all things that we're interested in as a science and technology agency looking at the measures, the metrics, the standards, hopefully to apply, to allow for innovation and application in many areas and quite frankly in areas that we haven't even imagined yet. So that's my five minutes. Great. Thank you, Matt. And one of the things that I hope we can come back to is what you were talking with the industrial Internet of Things, which will be an important part of productivity growth. But that's a little different than what Hillary's going to talk about. Maybe not. Maybe not. Who knows? I probably don't need this microphone because I have a very loud voice so I will try to not scream into it and if I'm making anyone deaf, raise your hand and I will make note of it. So there is no question that vehicles are going to be a part of this Internet of Things as we move forward. The thing that I struggle with and where I wanted to start right now is talking about sort of what form that's going to take, right? Because I think there's this Internet of Things idea that gets thrown out there a lot and as it applies in the vehicle space, I think there's questions about what that means. And I'll give you some examples of how we're trying to slice and dice it. You could have Internet of Things in the vehicle in the context of the multimedia systems that are now becoming sort of ubiquitous in vehicles. So that's, you know, when you get in, newer cars have that screen so that you can access the Internet from it. You can, you know, check your, you know, open table account, make a dinner reservation. You can do things like that. That's an Internet interface in your vehicle. I personally don't think of that as the Internet of Things. I think of that as a new sort of mobile platform, right? The same thing as your smart phone is just now embedded in your vehicle. But some people think of that as the Internet of Things because it is the Internet in a thing, right? Then you can have, no, and I'm being serious here. Because when you talk about the policy implications, they're very different for that versus, you know, some other forms of Internet of Things. You can have what Matt was talking about in the context of an airplane in a vehicle, right? Sensors that are monitoring what's going on on the vehicle, trying to detect anomalies or issues that need to be addressed. And that information being transferred to somebody who can do something about something that's happening in the vehicle. That's sort of your industrial Internet type idea. You've got Internet of Things in sort of the context of vehicle-to-vehicle communication and vehicle-to-infrastructure communication, which we are just now on the cusp of seeing. This is technology that's already been deployed elsewhere in the world but is now very close to coming to be in the United States. And this is primarily going to be used, at least in the early days, for crash avoidance, right? The ability of vehicles to be able to detect a possible collision threat and take action to avoid it. Okay, the idea here is more than 30,000 people a year in the United States alone lose their lives in car accidents, right? Which is a humongous amount of people, if you think about it. I mean, it's sort of equivalent to like two jumbo jets like falling out of the sky, you know, every week, right? That's a lot of people that are dying every year on car accidents. And what we're finding is we're not able to make sort of gains we want to make in that area by addressing what happens to a vehicle when a crash occurs, right? Where we're going to make significant gains moving forward is preventing that crash altogether. So this vehicle-to-vehicle and vehicle-to-infrastructure communication is going to enable that. Toyota's vision is that eventually that sort of communication capability will be augmented or supplemented with automation in a vehicle so that the car will not only sense that a collision threat is occurring, but then actually the car itself will take action to avoid it, right? So it's a combination of sort of the sensor-based collision avoidance technologies you're seeing now with increased automation, coupled with this V2V and V2I environment and we can sort of do a 360-degree crash avoidance system on the vehicle and prevent those crashes altogether. You know, and I wanted to draw this distinction because, like I said, for that first category, I don't see that as Internet of Things. For the second category, the sensors detecting problems within the system, I do see as the Internet of Things. And certainly the V2V and V2I system I see as the Internet of Things. There are a variety, I know we're going to delve into this a little bit later, a variety of policy issues that are implicated. I'm not going to talk so much about that first category, which I am saying is not Internet of Things in terms of the policy issues, although we see a lot more concerns about privacy in that space than we tend to see in the other areas. But we certainly do have growing questions and concerns about privacy of drivers and consumers. People seem to think that they, and I'm not saying this is not correct, seem to think that they have a greater entitlement to privacy in their vehicles than they do when it comes to their smartphone. It's sort of an extension of their home or something. It's very weird, but it's there, it's real. We hear it, we feel it, consumers tell us the car is a special place. There are obviously growing cybersecurity concerns. Those tend to be with that coupling of the communication with the automation, right? So if there's the ability for someone to hack into your car and take over the electronic operation of your vehicle, tell the car to brake or make a sudden left turn, you could have a bad scenario, bad things could happen. There's also a unique, well, okay, I'd say unique and then I'm gonna say it's not unique and then I'll stop talking. It's unique, a unique issue with liability, right? People seem to think it's unique to this concept of smart cars, but I would argue it's unique to automation in general, when you have systems making decisions rather than a person making a decision, who's responsible if something goes wrong, right? So in the context of a self-driving car, if the car breaks when it's not supposed to brake or accelerates when it's not supposed to accelerate and something bad happens, who ultimately is responsible for that? So there are questions around that. We've also got a lot of concerns in the regulatory space. I can be honest that the government is slow, is slow, not NIST, I'm not saying NIST is slow, but the Department of Transportation is generally slow on sort of where the industry is headed. There are some who would argue that there should be no regulation. I think everyone would think that was great at Toyota or any other auto company, but the reality is the auto industry is not ever going to be unregulated. So that same sort of tendency to regulate, I think will hold true in this environment. And if that's the case, we need the Department of Transportation to be moving quicker. So I'll stop there, I have lots more to say, but I can say it probably won't answer the questions later. So again, my name is Mark Reiland, I work for Amazon Web Services. And not surprisingly, my theme is gonna be talking about how we see a strong linkage between internet of things and cloud computing. You have on the one hand, billions of devices generating tons of data that people have not had managed before. On the other hand, you have these powerful new worldwide platforms where you can essentially rent compute storage and so forth, essentially by the hour or the gigabyte. And so not surprisingly, when you look at the startups like Nest or like Dropcam or a bunch of other, the players, the people doing all kinds of the sensor type applications on the end user devices, what you'll often see accompanying that is the use of cloud computing on the back end. So that raises some interesting issues around things like security, around things like analytics and so forth. So a couple of trends that we see. First of all, I'm gonna challenge a little bit the assumption, I think that mobile platforms are not the same. I think there's a kind of continuum there. For example, I think all of you right now are essentially sensors for probably some networks. For example, if you use Waze for your mapping, you are a sensor in their network, which is continually feeding back into their environment. And we're seeing, there's an interesting government and policy implications of that. For example, in the city of Boston, it developed through a hackathon, some people proposed an idea, which they've adopted as an official city program. Now it's called Street Bump. You run a little application in the background on your phone and the application's looking at the accelerometer. And of course, people get jostled and their phones move, et cetera. But if it happens that thousands of people always have been jostled in one place on the road all the time, every single time that you pass over that place, guess what, there's a giant pothole there. So not only do they know exactly how many citizens are affected by potholes and how bad they are, now they can actually do prioritized street repair. And those of you who know Boston know this is a very important topic. And this is by essentially, it's a citizen sensor model. The citizen becomes, in effect, an extension of what the government needs to know to accomplish its tasks. And there's many varieties of that, although from the sort of pure private play, like the Waze play, the Street Bump is a government program. There are other vendors, there's a company called Moveit, which is a private vendor that's working with city governments around the world to, again, create the sort of citizen sensor model around public transportation. So Moveit is an Israeli-based company, runs completely on Amazon on the back end, and they now have dozens of large cities and many other communities have integrated their bus and train platforms with the Moveit application zone that not only can the citizen or the user get a better service from this public transit system, but that public transit officials can get constant feedback about what's going on in their own system data that they never really could get before. So I think there's an interesting sort of transition now from the mobile platforms into these kind of Internet of Things scenarios that we see going on. When you're acquiring all this data, one of the things that was going on at the same time, people always talk about big data, right? We've all heard the big data bus word. But one of the characteristics I think that's fair to say that's new in terms of data is that people are storing things when they don't know whether it's useful or not to store them. That could be one sort of property of big data, if you will. In the past, we never really thought, we didn't want to waste the money, so to speak, on data that we didn't see any immediate use for. Now people don't have that attitude. The attitude of commercial concerns and more and more government is, storage is so darn cheap, let's just store everything. Later on, it may turn out that the data we're storing has really powerful properties and unique capabilities. But then what we turn ourselves into is we turn ourselves into data scientists. We explore data, we look for correlations, we hope there's causation behind those correlations. And it very much changes how you think about data and how you approach data. And Internet of Things is very much playing into that, allowing you to, let's just store this data for three months, then let's run a two week project to see if there's value in the data. And if there is value, we'll keep it and we'll augment our use. And if there isn't, we'll throw it away. And we'll only pay for what we're using. We're not gonna buy a ton of new equipment in order to do this kind of data exploration model. So that's another kind of correlation that you're seeing. And the final theme that I wanna bring up is the security theme, which has already been talked about. First of all, I think, unlike the old, well, so actually two more things, security and standards, they go together. Or can go together. On the security front, the theme that I wanna bring up there is people are having to rethink about how they conceive of security because the old perimeter security models just don't work, right? You can't think of the network as like, I'm inside my firewall, there everything's good and safe. And it's all, no, you can't think that way. You have to think, you've got this ubiquitous network, everything's connecting to everything. So how we think about security is gonna have to be in terms of the protocols, application security, defense in depth, all the kinds of things that traditionally we could not think about so much now, they're gonna be pushed right into the forefront. And again, this is a theme that has already arisen in the mobile world and I think will become even more important in the internet of things world. And finally, on the standards front, I've been in this industry for 20 some years and I've been through the various standards. I used to work for Microsoft, so I've been through some standards wars. The whole tenor of the industry is very different right now. Yes, there'll be some disagreement about, well, should we do this protocol or that protocol? But between the open source platforms driving, for example, data analytics, I mean, if you want state of the art data analytics, you're using Hadoop and Yarn and Presto from Facebook and things like that, a Redshift platform we have written by the hour, very, very different model than the traditional years ago when people would have to choose like a fundamental data architecture that was not interoperable with other people's architectures. And the protocols are pretty much all out there and defined for very lightweight devices. Everything is gonna have a TCP stack at a minimum. There are a lot of open protocols for lightweight messaging. Slightly more powerful systems will have HTTP and they'll use TLS as first secure transactions. All these things are, you know, rest, it's all kind of out there and the differences between the different approaches of interest will take a really small actually and they're really easy to write gateways and bridges between. So I don't think we're gonna have a big standards war like we might have seen 15 or 20 years ago around this technology. So I'll pause there and look forward to the conversation. Everyone knows what to do, Piz. Yes, why don't you just explain the open date and Matt, if you wanna jump into, because this is a crucial point in some ways and then we'll go to Jeff. Yeah, just briefly, it used to be when you wanted to deal with massive amount of data, you have to have a giant computer, like a really big, powerful computer and it was really, really expensive. And then along came internet companies who said, you know what, we have thousands of little computers, why don't we stitch them together and make them to jointly run very, you know, very, very fast operations across gigantic data sets. So you can think of Hadoop as a computing framework which horizontally distributes work across commodity computers in a network and enables you to do work that would have previously cost millions of dollars to buy a computer. Now you can do for hundreds of dollars on a thousand inexpensive machines. Although I will confess I do miss my deck 10. So, Jeff. So thanks to everyone for coming today. Jeff Green with Symantec, although today I will be speaking for at least my initial comments about some work that I did as part of the NSTAC which is the National Security, President's National Security Telecommunications Advisory Committee. It's a presidential committee of presidential appointees. It's been around since 82, typically senior execs or CEOs of telcos or other network service information technology companies and then they have their designees who do a lot of the work on the day to day. This is run now out of DHS and the way the NSTAC operates is by doing studies and reports that go to the president and this past November the 19th, the NSTAC approved two reports, one of which was an Internet of Things report and I co-chaired the staff working group that developed that. So that was about a year's worth of work. Began in October of 13 with a scoping effort followed up by about an eight month study and writing period. Throughout that process we met with dozens of subject matter experts. We had some field trips, a lot of interesting debates. So it was a long process leading up to the report and what I'm gonna do today is just give a summary of what we found and what some of our recommendations were. I'm not gonna read from the report with one exception. I think that there's one passage that I think summarizes and this is only 50 pages which for a government effort I think is pretty good but there is one 39 word summary that I think captures really where the report came out and I'll read that piece. There is a small and rapidly closing window to ensure that IOT is adopted in a way that maximizes security and minimizes risk. The country fails to do so, it will be coping with the consequences for generations. There's a lot going on in the short quote and one of the key points I think it tries to drive and if you go into the report, the preamble is that there is a lot of opportunity in IOT and the report should not be read as a sky is falling, this is a bad thing. There are a lot of good things that are gonna come out of this but beyond that, if you look at the word choice it makes clear that there is no perfect security. So it talks about maximizing security and minimizing risk and that should be our goal. We can't set unreasonable targets. Then there's the short timeframe, we're in the midst of IOT adoption, it's not something that is coming over the horizon but finally the report puts the window of that timeframe between two and five years to influence IOT adoption processes significantly and then the consequences of getting it wrong that'll be with us for decades. Some of these are gonna be significant, some of these are not. If your Wi-Fi enabled toothbrush is hacked it's probably not a big deal. If the water system is somehow penetrated or compromised or the power system that supplies electricity to your Wi-Fi toothbrush, that's a bigger problem. So in terms of our key findings, this is my shorthand, these are all in the dock. It's by no means everything that the report had in it but the first finding I mentioned earlier is that IOT is here now. It is here from personal use in citizens to government use in defense, in disaster response, in transportation management. It is being used today. It is in the industry, in manufacturing, in fault detection, in ordering processes. It's in critical infrastructure. IOT devices, sensors, et cetera. And they've been around for a long time and they weren't always called IOT. So one thing I think to understand is this is not a flip a switch. The internet went live for the public and a certain date. This has been a gradual evolution and this name is being applied to things that have been around for quite a while. Next finding was the cyber security implications of the IOT. We're talking billions of new end points, some of which are very small. I've read about future Happy Meal toys that have sensors and wifi in them. I don't think we're that far from that. Things are getting that cheap. But now we have kinetic concerns because things live and move in the real world and impact things that move in the real world. And you have devices, whether old that cannot host security on board or new ones that just aren't being built with it and aren't gonna have the compute power or the processing power, the battery power to run it. And then you're gonna have unseen and unknown connections and that gets to, we're gonna have devices talking to devices, making connections to other devices without any human impact. And also we're gonna have devices taking action. So if you go to Matt's peanut butter policy, he talked about his fridge telling him he should go buy peanut butter. But his fridge may alert the local supermarket, Matt needs peanut butter. And then a machine is gonna pick that peanut butter and put it on the truck and he's gonna have peanut butter and he's not gonna be involved in that decision. What's that? The Amazon drone will deliver it. And the Amazon drone will deliver it exactly. We're Hillary's car sensing the action around. All these things are happening without human interaction. In Hillary's case and the car's case much faster than a human could react, which is why we're doing it. But that brings some risks that we need to take care of. Another finding was the line between consumer and industrial is disappearing. In the past, no one had a home power generation system but now you can buy an industrial control system in a box from Lego called Lego Mindstorm. It is literally a soup to nuts industrial control system. You can take it home and play with it. It's actually very cool. But you're seeing industrial move in other ways. 3D printing we have at home. Autonomous system, I mentioned toys. But we're gonna see the reverse though and that's where you potentially get some risk which is hobbyists that are using Raspberry Pi or Arduino they're gonna start building things that are gonna find their way into systems. Some intentionally, some not, that are connected to or even empowering critical systems. And if that happens, all the vulnerabilities that were inherent in this hobbyist device are gonna be ported into critical systems to the country. IoT is also a convergence of information and operational technology. It was often described as a conflict or a collision between the two. And you have very different approaches to security and particularly cyber security in those two disciplines. In the operational technology world, you're talking about lifecycle of machinery that lasts in decades. You're not swapping out power generation plans or water control systems. We're talking decades. IT are looking at years. OT worries about physical security guards, guns and gates. IT is more virtual security. And in terms of reliability, the holy grail of IT used to be your four nines which still allows you time to update your systems, take them down if you need to. But you can't take down a water pump to update or patch the latest, patch Tuesday you can't take down the water pump that's feeding the Washington area. So it makes it very hard to align the needs of IT and OT and that creates gaps that potential adversaries or just people looking to make new sense can exploit. Also you have older OT that was built before network computers now being connected to network computers which creates issues. Current governance structures are inadequate. IT technology is moving faster than IT policy. Technology always moves faster than policy but the report, the NSTAC concluded that in this case the gap is widening more than it normally does. It's reflected by the fact that fairly recent national strategy documents for cybersecurity don't mention the IoT. And in fact there are many definitions out there in other government and private sector documents that end up being conflicting. In terms of the recommendations, and I promise I'm getting towards the end, we broke them into two groups or the report I should say broken into two groups. There are some immediate recommendations and some near term. It's noteworthy that nothing was perceived to be long term because this is happening so fast. In the near term, in the immediate term, the first thing is that NIST, I think Matt, you were named by name in the report, Matt Scholl needs to come up with a definition. In a good way. Scholl needs to come up with the Scholl definition for the US government. And I should say something about these recommendations. The ANSTAC reports go to the president and the recommendations have to be number one at a presidential level and number two actionable for the president. So it's not gonna be direct the private sector to do X or Y. It will be what can the government do in certain areas. So the first one, the Scholl rule was that NIST should define for the US government what IoT is. So it's not gonna be probably the last definition but at least a definition that the government can then use to determine how it is now using IoT and how it's gonna use it in the near future. And through that look at what interconnections and interdependencies they've come up with and start coming up with contingency plans for managing the inevitable threats, vulnerabilities that are gonna be spread around through them. Another short term recommendation is a government wide task force to plan US government strategy for dealing with IoT, identify gaps in practices and technologies and then update awareness and training both internal to the government and any public efforts that we have going out there. Someone who buys a Fitbit doesn't think about the connections that device has. It's probably not a, I've seen, I got one in my pocket, I see two up here. There is some security in connecting it to my phone. There's not maybe as much as some would want but people need to think about, be aware of the data that's being passed around. And also, and encourage academia to develop IoT specific programs. And then in the near term, convene a public-private partnership to work on IoT deployment guidelines, manage related cyber risks and implications. The two structures that were mentioned in the report are first, the process that NIST used to develop the cybersecurity framework. And second is the CSIS report to the president, 44th presidency on cybersecurity. So a little advertising for it there. But those two were called out as processes that the NSAC thought had worked well. And then develop updates for communication and priority communication schema. Your 911 calls, other national security telephone calls go through what do we do with national security data? We need to find a way to prioritize that so it doesn't get lost. And then finally, NSAC recommends that the president ensure that federal R&D investment includes sufficient focus on IoT security and through that drive this education and training that we need. We talk about education and training in cyber constantly because it's important. The problem I think is a little greater in the IoT though because there aren't really programs or many programs dedicated at that aspect of it. So that is emphasized. So with that, happy to take questions on that or anything else in this area. Great, thank you, Jeff. I have a lot of questions, so maybe I'll start. And I'm gonna start with one that comes from a story Hillary was telling me a while ago, which is that there are cars, if I got the story correctly, in Japan where they have the ability to see around the corner. And I misstated that intentionally because that's how I heard it and it wasn't true. So think of a blind corner and the car will know in advance what is on the other side of the blind corner. I thought that's really cool. I don't know how to do that with a sensor. And turns out it's not an onboard sensor. It's not a good sensor on the car. It's sensors built into the infrastructure on the other side that are communicating with the car and saying, hey, slow down, there's something. So let me start with that question for all of you. And Hillary, maybe you wanna go first. What are the essential infrastructures we're going to need to invest in as we move ahead and people talk about smart cities and smart airplanes and what's the infrastructure? Part of it, I'll cheat. Part of it clearly has to do with spectrum and spectrum management, but what else do we wanna think about? Right, so I'm happy to start. And what you said is correct. So Toyota, we have a really interesting vantage point, because our global headquarters are in Japan and so we've been able to experience what's been happening in Japan with intelligent infrastructure versus what's been happening here in the United States, which is nothing basically in the United States. But Japan, the Japanese government years ago decided that they were going to commit resources and support to the build out of intelligent infrastructure that could enable the sorts of things that Jim's talking about. So in 2009, which was a while ago in the grand scheme of things is when companies like Toyota began to deploy these vehicle to infrastructure systems where there is infrastructure detecting those sorts of things. I'll give you a couple of other examples. Challenging merges, right? When you know when you're driving down the highway and all of a sudden there's like a merge and it's like right on you and then everyone's breaking and it's uncomfortable. Being able to communicate to your car, hey, you're coming up on a merge, there's cars there, it's gonna be a little bit challenging so slow down or speed up or whatever. Another example, you know how you drive into a tunnel, right, and you're cruising along and then all of a sudden you turn a bend and like cars are stopped, right? And brake lights everywhere and you're slamming on the brakes, these technologies would tell you there's actually stop traffic 100 feet ahead. Those are sorts of examples. From a marketing standpoint and commercialization standpoint it makes a lot more sense to start with vehicle to infrastructure than vehicle to vehicle communication, here's why. I'm an early adopter of the technology, let's say. I drive my car off of the lot, it is enabled, it can talk to other cars, it can talk to infrastructure. I drive off the lot and there's maybe two cars that my car can talk to, right? Not very valuable. But if there's infrastructure out there, I get an immediate benefit as an early adopter, I drive off and I'm getting information that nobody else on the road is getting, right? Like so, but so we started with V2I in Japan, we are going to start with V2V in the US most likely because there is no infrastructure and as a result, my guess is the technology will be adoption pickup will be slightly slower in the United States because for those early adopters you're not getting much when you drive off the lot. All this is to say that the United States needs to get its house in order on this intelligent infrastructure piece. We're seeing some collaborative work taking place in Michigan right now between the federal government and the State Department of Transportation and the University of Michigan and we need to start replicating that in other parts of the country so that we can realize the benefits of this technology here. So I would start with we need to think about the security of it and we need to think about it from multiple angles, not just on the device itself, but you need some type of system that is looking at that data and doing a common sense check. If it tells me that there is stop traffic but I have other sensors telling me cars are moving, something doesn't add up. We also need to think about, as we're designing these systems, not just think about how they can be used or we expect them to be used, we need to think about the way they, any way they could be used. And the example I would give, somewhat analogous, I was at a conference a couple years ago and gentlemen was showing how he had spoofed the AIS system for ships, which is essentially monitoring, ships tell each other where they are and they're all equipped with it so it works. And this guy bought about 3000 bucks of equipment, set it up in his apartment in Manhattan and if he didn't go fully live, thankfully, but if he'd gone live every ship in the region I would have thought that there was a large ship sitting in the middle of Manhattan. Need example but if someone gets out in the open water, you could create a lot of havoc with something like that. So we need to understand that once we build something like this, we may have certain intent as to how it's gonna be used but in the end it's a dumb box with sensors and actuators and people can use it any way they want. So we need to have that attitude from the get go both in terms of security and design. So. You've got numbers. Yep. Thank you. I have to remember the button. I need an automated sensor here for turning my microphone on. We need a voice control sensor that would let me. I think history tells us that when you, a lot of these problems can be addressed with the government encouragement of open technology and then of course industry buy-in to these things. So for example, I think it's done a very good job with the smart grid work that they've done enabling a lot of vendors and power companies and all the stakeholders to get together and sort of jointly define roadmap and so forth. So those kinds of efforts I think are very worthwhile. But in the meantime, there's a lot of infrastructure out there now, sort of ubiquitous 4G networks. For example, city of Houston is one of our customers. They have more than 400,000 power sensors out in the field taking 32 measures a day, billions of records accumulating of power usage. And they didn't have to build an infrastructure to deploy that. They had to deploy new meters, but not fundamental new connectivity and so forth. So there's a lot of opportunity with the infrastructure that exists and the open markets with good government guidance and input to solve a lot of these problems. Stole my smart grid example. Ah, that's okay. Oh, I set it up for you. So smart infrastructure is one of these use cases that we think holds a lot of promise. And one of the ones that's been working on for quite some time, which initially the government got interested in under the Energy Independent Security Act, which asked NIST to perform a convening role with industry working collaboratively with the Department of Energy to incentivize the use of a smart electric grid. I'm not sure what that means about the old electric grid, but it really was talking about same concept of sensors, machine to machine communication, dynamic allocation based on policy in order to allow for a more efficient, more effective, more resilient electric grid for the nation. That's just one example of an instrumented infrastructure. But a lot of this needs to be looked at in context of the entire system in itself. NSF in the last couple of weeks released what they call the Smart Cities Challenge, where they are looking at cities to participate with NSF to look at this entire kind of environmental look at instrumentation and sensors within a city, so that we don't run across if we're doing point infrastructure deployments, spectrum management issues, for example, or data collision issues. Not only that, but as Mark kind of mentioned, what are the sensors that are currently deployed, that are potentially doing other things for other use cases that could also be repurposed into new knowledge sets and knowledge bases? So the look around the corner sensors potentially could also be traffic congestion sensors that could also tell you when traffic is lightest. And then that goes back into the smart city design to say, all right, when do I bring in my big trucks to resupply? Well, then I can have data to understand when that affects my commuter population the least or the most. And then make some decisions around distribution of resources, energy, and goods and services and people within my city to the greatest effect and efficiencies that are possible. So this kind of needs to be looked at in a large mechanism to avoid potential conflicts and also to leverage existing systems into these new knowledge-based discoveries that we're kind of trying to derive from. I mentioned Waze. Who knows, raise your hand if you know what Waze is. Okay, yeah, pretty good. Okay, so Waze is a mobile app that you run and you use as a mapping as mapping software, but the unique capability is that it's uploading your speed and distance as your vehicle moves to the system and thereby creating crowdsourced but very accurate real-time data about. So there's another kind of bottom-up solution to these problems, which is if you get enough people essentially on a volunteer basis who are willing to contribute into these systems, then now I do have real-time data about traffic jams all around my neighborhood. Now maybe it's not quite to the granularity of, hey, there's a slowdown around this corner, but even there, I mean, driving to DC all the time from the Dulles area and I know for sure whether there's a quarter mile ahead, or whether it's gonna be that bottleneck between I-66 and the 267, I mean, it's right there. I feel very confident when I see all the little red lights and the slow crawling icons on my screen that there's something going on there, so yeah, that's true. I guess that's not a good example since it's always there. Anyway, so it may be that the creativity of people working in open markets and the fact that consumers can benefit from lots of these technologies will enable some scenarios that don't require a kind of heavyweight approach. So I wanna just tag on like, so there's one distinction I wanna make, because you're absolutely right, and I wanna note that in terms of what I was talking about with the vehicle infrastructure piece of this, that's less, the stop traffic in the tunnel, right, is less to know about that there's congestion. We can know that from ways or a navigation system that can tell us there's some congestion coming up. From a collision mitigation standpoint, though, we need to know exactly where that car has stopped in order for your vehicle to, so I just wanna, you know, I wanna make sure that we're not going to be using ways for collision avoidance anytime soon. I don't anticipate, so. I'm gonna cheat and ask a second question, then we'll go to the audience, but I think Jeff said this, and it's something I've been thinking about for a while because it comes up in the larger issue of critical infrastructure protection, and that is how do you manage the what we would call the refresh cycle, right? And so in critical infrastructure, the refresh cycle is about 20 years, so there's still a few places that are using Windows 98, and, you know, as a hacker, you wanna thank them for that. How do you deal with the refresh cycle? Cars, the average car, what's about 10 or 11 years? 12 years, right? So that means if we had the perfect smart car today, it would not be fully deployed until really about 2027, right? How do we deal with the refresh cycle? Do we just let the natural cycle take its path? How do we deal with patching? How do we deal with updates? We, you know, this will be an incremental process at best. Do we wanna try and accelerate it? Okay. Yeah, so if we look at this granularly where these are chip-based, very lightweight sensors, very inexpensive, very low power, low bandwidth, low CPU, as was one of the examples that was mentioned, and you just look at it from the sensor aspect, the refresh occurs above at the virtualization stack and at the API stack or even in the backend analytic, and then the sensor itself is as much as possible, just a hardware-based sensing device. The other mechanism is rather than refresh or redeploy is just ignore, is where if you do, if you have a decent identity management system to identify the sensor and the data coming from the sensor, instead of refreshing or pulling it, you just turn off that data or you don't allow that data into your analytic stack. And then if you need to, you redeploy. Oh yeah, the technologists have learned, I think, over the last few years, certainly when you're building new applications and new systems that making updates frequent, easy, painless is a critical part of building a highly reliable, robust system. And the idea of agility and infrastructure is a key part of what's going on. Again, use the mobile phone example, the apps are completely containerized. This is the problem with your PC, right? When you install an app on a PC, try moving it to another PC. It's almost impossible. You have to reinstall everything. Mobile phone, the people had learned by then. No, it's containerized. You had to delete on the icon. It literally deletes every single element of that app because it's containerized. The operating system knows every single trace that app has made and knows how to get rid of it. Similarly, server-based containerization is a hot topic. For those of you who follow the IT industry, you'll have heard of things like Docker and other technologies that allow you to do server-based containerization. And ubiquitous refresh and deployment. So amazon.com does more than 100 million software deployments every year. Thousands and thousands of deployments a day. In real time, system never goes down. One user may have to hit refresh if they happen to be, hit a low balancer that happens to hit a server that's being rebooted. They get refreshed. They get functioning app. That's the way modern software is developed. I think these techniques, if we're smart, and I think the industry building new things, now the legacy infrastructure, it's a different question. But if I'm building even a very lightweight sensor today, a very, very lightweight piece of hardware with very minimal pieces of software, I'm gonna have two pieces of software on that. I'm gonna have the main system application, whatever it does, and I'm gonna have the updater. And the two are completely independent. The updater, I can signal to reload the device. And then the device does its normal function. But those two will always be there so that I can remotely upgrade all the devices. Any design that's not like that is crazy. So I think going forward, we have some good solutions to these problems. Legacy infrastructure, of course, is gonna be an issue, but I think it's a very good point that we can ignore data from sensors that we know are not up to date or not fresher that have been hacked or something like that as part of our analytics system. So there are solutions even to that problem. Yeah, I would say in terms of how are we gonna roll things out quickly if we have this slow refresh cycle, the things that are gonna come out quickly are what can, whether apps or devices that can jump onto an existing platform like Waze, which is taking advantage of sensors that were deployed with, were never intended to be used for that purpose. And the most successful things we're gonna see are gonna do that because otherwise it's gonna take too long to get it out there. From a security standpoint, the back end analytics that Matt talked about are gonna be essential, I think for, definitely for the legacy, but also for the future. You're gonna need some type of system that is watching to see does this data make sense? Is this device acting in the way that I expected to or should it be communicating right now? And it's gonna have to talk to the older systems and find a way to machine learning and also provide feedback on the new devices we need to find a way to as, definitely get the authentication in there as Matt was talking about, to find out what's the old New Yorker cartoon on the internet, no one knows your dog. On the internet, how do you know, you can claim to be a sensor, but you may not be, we have to make sure that those sensors actually are what they claim to be. And then there are multiple other ways you're gonna need to secure them, but that's gonna depend upon the use. The Wi-Fi toothbrush, and I'm not making that up, there is such a thing. It was actually Amazon deal today, if anyone, a few weeks ago. I thought about buying it, my wife wouldn't let me, but probably not a lot of security needed there, but other devices, it's gonna have to be situational. And so, Al and I, I do think we have a particular challenge in the vehicle space. As you mentioned, people tend to hang on to their cars for on average 12 years, which is a very long time. So it will undoubtedly take a fair amount of time for us to realize the full potential of this vehicle network. There are ways to accelerate that. There are conversations going on about aftermarket devices that can be plugged on to a vehicle to make it part of the network before it's, while it's still on the road. One of the things that I think is interesting that I wanna throw out, and it's resulting, and I'm not gonna get into details of it, but we're sort of embroiled in a spectrum battle right now in this space. And one of the arguments that we've heard from the other side, the folks who are interested in accessing the spectrum that's been set aside for the vehicle system, is that it's going to take a long time for this network to come to be, and there are ways that this spectrum could be used right now in a more tangible way. And I find that argument always to be a little bit funny, right? Because if everything we did was about the potential of today, and not about the potential of 10 years from now, we would be sort of stagnant, right? So anyway, it's a recognition that it's going to take a long time in the vehicle space. There's no doubt about it, but it does not mean that it is not worth doing. For a while, the working title for this project was on the internet, no one knows your refrigerator, but nobody seemed to like that. So do we have, go ahead. Can we get a microphone up to some of the questions? Thank you. Excellent panel. Jim, thanks again for these excellent programs. Yesterday at breakfast, the NERC official basically capitulated when dealing with the security issue, saying there's very little that we can do in our space if we don't have a revolutionary technological solution. And that really juxtaposes security against application, efficiency, and what have you. It was mirrored in a comment by the second largest world supplier of generators who basically said that security's on the risk side of our ledger, and it's really not gonna do much unless it's on our income side. So can I get comments from the panel with regard to those two perspectives? Matt seems ready to roll. Yeah, pardon me, I'm leaping out of my seat. So I think we're seeing a business shift occurring mostly because of recent events where there's becoming a stark realization that security is a business issue. And that businesses who function looking at business risks that they do, be it customer risk, supplier risk, financial risk, economic risk also need to integrate cybersecurity risk into that business risk stack as they look across this whole issue of risk holistically rather than dealing with cybersecurity risk in an isolated pipe off to the side. That way, cybersecurity risk for businesses will be looked at in the context of the business and in the economics of it. We don't do security for security's sake unless you're a security company and security is your business. You do security to support your business. And I believe that is becoming more and more realized where people are understanding that security and business are not in conflict, but rather that security supports business. Revolutionary technologies for security would be wonderful. But more often than not, it's the sit down, thoughtful risk management decisions and sound standardized application, the hard grunt work of the guys that used to be in the back server room but are now more out trolling with your customers that really provide you with some of the best bangs for your box on security. So we can all sit around and wait for that revolutionary silver bullet or we can sit down, think about our assets, think about our threats, conduct some integrated risk management and make some good sound risk decisions that support our businesses. So that's kind of my soapbox that I'll get off now. The only thing I would say is that when I first started working on this issue, back on the hell in 09 timeframe, the mantra we heard was we got to get the C-level, pay attention, C-suite needs to pay attention and C-suite doesn't care about cybersecurity. And I think that is an old talking point now for the reasons that Matt talked about. So I think that to some degree it's still gonna be on the expense side, but there is a lot more attention at the high level of corporations that is enabling, we're not there yet, but I think there's been a significant shift. So I think you're seeing companies view it as, in the same way that you lock the door in your warehouse so no one walks in and steals your goods. You need to lock the virtual door too and we're getting more to a world where those things are equated as opposed to cybersecurity and being something you will do if we have a few extra dollars. So I think we're getting there slowly. Let me ask a kind of a mean question, but I'll ask it anyhow. Where do we need to regulate first? What's number one on the hit parade for regulation? Is it privacy? Is it something else? Where do we need to regulate first? Stump them with this one. Back. I don't think it's privacy. And I don't know, some folks may be aware of this, but just a couple of weeks ago in recognition of sort of where the automobile is headed and growing concerns about privacy, the auto industry got together over last year and two weeks ago we unveiled some self-regulatory code of conduct to try to calm some of the growing, I would characterize it as hysteria around what may happen in the vehicle space and put some restrictions, pretty meaningful restrictions I would argue on our use of vehicle data, things like we will not use it to market and market to you, we will not share it with third parties without your consent, things like that in an effort to sort of address some of those concerns. So I think that a self-regulatory approach is probably more appropriate there. The problem I was mentioning earlier for the vehicle space is cars are so heavily regulated by the Department of Transportation. I mean, we can't do anything without getting knits to bless it. And it's certainly going to be the case with these new vehicles. And so we've got a couple of rule makings that are pending or not even yet started and it's one around autonomous vehicles, self-driving cars. I don't think Knitsa has much of a clue where to begin. These are hard issues and hard questions but the time is now to start that process. And also there's a pending rule making, which just started on mandating this vehicle to vehicle communication capability in all future vehicles. And that is rather slow going as well. And I think a lot of folks are interested in those being done more quickly if at all possible. Jeff, do you want to say anything about where the report came out on this? So report did not come out at all in favor or discuss regulations about the IOT. It talked in terms of voluntary effort within the government and then the public private effort to come up with deployment guidelines. I think the biggest reason and it's written in the report is that there is this, we are so early in IOT that we can't yet define it. And if we come up with too strict a structure around it, we're gonna limit the innovation of it and potentially the security of it too. That's why this idea of getting a public private together and trying to drive the awareness of it. And I mean, in general, I think we need to look at existing regulators rather than new ones and make sure that they get what they're doing in the cyber realm, whether it's NHTSA or whether it's FTA, be smart about it, make sure we're not limiting deployment of both security and new technologies rather advancing it. I think you have to look to what's going on currently before we're gonna look in the outside. Thank you, Nick Farmer, a private citizen. There seems to be more emphasis that maybe next year the federal government will start to invest more in infrastructure. Do you think it's possible that they could be convinced to devote a good bit of that infrastructure spending on IOT related things, which in my judgment would be much more efficient, both from a capital deployment, energy deployment and environmental impact than building more roads, more airports, more harbors, more railroads, just use the ones we have more efficiently, which the IOT allows you to do. Could you comment on that? So I mean, I'm gonna kind of take it down a stack into it's where I operate in the technology space. It might not even be an either or, but rather if we are going to invest in new infrastructure, the new infrastructure should look at how it can use IOT for smart, sustainable infrastructure that then can allow for a longer life cycle on the infrastructure, allow for more economic use of the infrastructure and to allow for easier and more economic maintenance of the infrastructure. So rather than pouring concrete or putting up a bridge, let's instrument it at the same time so that the new highway is already set up for that infrastructure to the vehicle communication. It's already put in a bandwidth considerations are already looked at those types of things. So you don't necessarily have to send out the bridge inspector every year, but rather the bridge will tell you send me an inspector type of thing. So I think it's, I think we'll have a spectrum of deploying IOT into existing infrastructure in order to understand it better and then deploying IOT into new infrastructure in order to understand it and maintain it as we go forward. An easy way to accelerate that would be for Congress to think about building it into any legislation or funding for infrastructure. And so that, you know, if you're trying to think how you would jumpstart the process, it would be to make this a requirement for infrastructure spending. Don't know, don't know if that's gonna happen. Wouldn't take any bets. We had a question there in the middle. Yeah. No, go ahead. Yeah. Yes. Can we get you a microphone? Joe Coulter, I know that the technology of the world is bad that they're using international standards. You know, I see more innovation overseas than I see here. What do you see as far as what you've been able to leverage internationally as far as international standards to help you advance innovation? That was the one thing I would, I don't have a direct answer. I would say that one of the findings that I didn't discuss in the report is that IOT is a global phenomenon. We cannot have US specific, whether standards, regulations, et cetera, that are gonna make any devices we have in the US not function with the rest of the world. We need to think about this as a global. That is one of the findings under the governance structure that we're current governance structure are inadequate because they are too vulcanized. Yeah, and obviously, you know, Toyota being a global company, we always have an interest in anything that we're doing. I mean, we don't wanna have to, you know, modify a car for sale in the US different than a car that we would sell in Japan. So international standards in this space are paramount. So the S and NIST, right, stands for standards. So we fully believe that the use of open, consensus-based, industry-led, international standards are essential and extraordinarily helpful for both innovation and global competitiveness in open markets. So I would concur with that. Did you wanna touch on this at all? I'm not gonna lay off the hook because it might be data localization as a standard. It sounds like a chorus of, yes, it's a great thing. I mean, I would say though that the internet, the ITF, the internet standards have been a really good example of how, you know, quick consensus-running code, the way to approach standards often is through proof of concepts implementation as opposed to more of a top-down kind of committee-driven structure. And I think we've seen that over the years that that is the case. And now that's kind of morphing into the open-source world in which people not only have, you know, write down the document, the standards, but they'll provide implementations. And many people have business models that allow them to give away those implementations. And so you often can see very quickly developing and very useful new technologies that come about through the agreement essentially to, you know, not only write down protocols and data specs, but actually to distribute code that people can reuse. So I'm very optimistic about, and it's very international. I mean, we have regions to play all around the globe and keep our stacks as, you know, identical everywhere. And we use the same, you know, standards for everything from things like multi-factor authentication standards. We use RFC 32, you know, 62, 38. And we, I mean, we use these things in their global in nature. And that's a big part of the success of these fast-developing markets. I think you've said excited people. So... So this question... My name is Eileen Hirshnow from Consumer Reports. And this question may be a little bit out of the scope, but I'm thinking... I'm wondering if, particularly in some of your companies or Jeff in your report, if these sensors include mics and webcams or something similar to that, or even if it's not mics and webcams, but data, to date for the national security stuff we see going on, they're most of the commercial targets have been telecom companies or soft, you know, social networks, the Googles, the Facebook. Have you folks, as you start developing this, have you been talking or on the regulatory side, talking about when you're gonna start getting subpoenas or government hacking? You know, I wanted to ask about consumer choice and control, but let's keep it to government right now, because now the internet of things is gonna have all this data that government might want, not just telecom and the Googles and Facebooks. Yeah, so I... This was something that the industry, the auto industries, we were working on those self-regulatory privacy principles I was talking about earlier. One of the things that we grappled with, and I can tell you where we came out on it as an industry, is we have all committed not to share information with law enforcement in the absence of a warrant. So we tried to be as aggressive as we felt we could be needed to be for our consumers on that front, but it is, in the vehicle space, it's particularly, we're finding growing interests from law enforcement in location information type, type that space, wanting to know where somebody is. So from a technology perspective, I will agree with you. Microphones, webcams, speakers, cameras, accelerometers, GPS sensors are all sensors that are taking the physical world and generating data from it, and then potentially from that sensor putting it back into a backend cloud. By the way, just described your phone, if you think about it, which is a sensor platform. So kind of what you highlighted is at a large level is just what are the security requirements that we should think about in order to not just assure the integrity and the authenticity of the data that's being generated, but to work on the confidentiality of that data as well. And what are those requirements and what are the technologies, the standards that are needed in order to assure that confidentiality? Be it encryption, an encryption that can be used in these small night-weight devices, low power, low bandwidth, low CPU, all the way through the security protocols and the communication stack to the security of the backend clouds and the analytics as well. We have plenty of questions if you. Go ahead, please. Frank Prouch for Lossy Tech Partners. As you start looking at machine to machine systems where we don't have humans in the loop, and we start addressing the fact that we have such wonderful threats as cyber and time denials and other things that go on, can we look at standards or mechanisms and processes that allow us to continue to operate? I envision a stage where my Toyota won't go in the tunnel because it doesn't know. All right, so what I don't wanna do is have the same circumstance that I have when I go to a grocery store and the power goes out and I can't buy anything because nobody knows how to use a calculator anymore. How do you keep from over-automating IoT to a point where it becomes our enemy? So I can address this from the vehicle space because this is actually something that I think the auto industry is struggling with right now and where at least Toyota has landed on this issue is for the foreseeable future, we are going to adopt an airplane model. By that I mean we all get on airplanes and we probably are all aware, maybe we're not, that those things are generally taking off flying and landing by themselves, but you still have two pilots in that cockpit just in case. And so for us, for the foreseeable future, we're envisioning that kind of a model in the vehicle that there will always be an operator in the operator seat or the driver seat who can take over manual operation of the vehicle should the car encounter a situation that it doesn't know how to handle or any sort of those environments. So we get dinged a lot about that, right? From sort of an innovation standpoint, this does not sound very innovative that you can't sleep in the back seat or send your car off to drop your kids off at daycare while you finish your morning cup of coffee. And I get that, but from a reality standpoint, this is uncharted territory, right? And we wanna make sure we get it right and there's gonna be some growing pains. There will be growing pains, right? This doesn't happen, it's not perfection overnight. And to address those growing pains, we're gonna go with the airplane pilot mode for a while. You know, Jeff kind of talked about the, this is kind of a merger between IT and OT systems. And something that OT systems generally do much better than IT systems is OT systems look at users as part of the system design. Whereas IT, we're very good at trying to isolate or get rid of users. So when we look at these type of IoT systems that are having these kinetic physical feedback loops, so it's not just generating data from the physical environment but it's going to then use that in a policy to make a decision that's then going to be sent back to some kind of actuator than to change the physical environment. The concept now is what is the failure settings of these devices? How do they fail? How do they fail safe? What is the resiliency model? I think Mark was talking about the old security concept of the perimeter, we could spend a whole session on whether or not it was even valid to begin with. But instead, how do then these things operate under compromise or operate in degraded mode safely and with a manner that does not have a negative kinetic impact? Yeah, Matt hit the resilience point that I was going to make and that is in the end stack report. Speaking as Jeff Green, I would say that we need to start asking, we need to have our developers ask the right question and the first question I think too often right now is can we connect it? The question should be should we connect it? And if yes, then we need to look at does it need security? If yes, what level of security and then have we put it in? But I think we need to start with the should we connect it? It's a little bit of the wild, wild west right now. I was at a conference, an IoT conference last spring and it had a show floor and some of the stuff was literally help, you know, cardboard boxes and duct tape with actual, and it was very cool, but some of it was, it felt like, you know, early 90s internet web pages, which was really neat, but I don't think we're asking all the right questions right now. I'll just chime in and say, you know, good engineering discipline should always require that you think about how things operate in degraded mode and I lose that connection to my home server. What do I do now? And so certainly that's got to be a key part of the design principles for these systems. You know, what occasional connection, disconnected operations, all these things have got to be key to designing reliable and robust systems. I think the handoff from the machine to the human operator will be one of the biggest challenges for all the devices and also the failsafe when the machine fails and when the operator fails, which we can almost always come on, what do you do? So those will be sort of the uncharted problems for this. Thank you. I'm Alan Schlafer with the Wharton DC Innovation Summit. You were addressing a bit some of the hardware and software reliability issues. There are also user education, example, cars. I have a new car, not a Toyota, but it's still a good car. And with a company that says innovation that excites, I would say that also puzzles sometimes because there are so many complexities. I was trying, I finally figured out how to use voice recognition and it was not coming up with the right stuff. You also have a problem with drivers, distracted drivers, distracted walkers. So how do we educate drivers on what have become much more complex vehicles? How do we educate the mechanics who are fixing them? And how do we keep drivers engaged so that if the machine runs into a situation where it can't prevent the accident, we still have a safe car to drive and hopefully avoid or minimize an accident. So yes to all of that. And I mean, I can tell you that, I don't think there is an auto company out there and Toyota included who's not spending a lot of money trying to get those answers correct. There are challenges with how you're sharing this information with how you have vehicles communicating information to drivers and you don't wanna do that in a way that is distracting, right? There are issues about the handoff between the machine and the vehicle when the car encounters something that it needs the driver to step in and help with. These are not easy answers to come up with. I can tell you though, ultimately with the driver distraction thing, a lot of this technology will probably help counter distraction, right? For example, so I've got a new Lexus with all of the bells and whistles for all the advanced collision systems on it. And I've noticed how much that car saves my rear end when I try not to be a distracted driver. I try, but I have kids, right? And kids are like really distracting when they're in the back seat. And that car has saved me multiple times when I'm dealing with the kids in the back seat and I take my eye off the road for a second and then the car beeps at me and starts breaking because I'm about to rear end somebody. So we think of this in some ways as a way to help address driver distraction or overcome driver distraction. That's one element of it. Do you wanna tell people your license plate number so we can know? But I'm okay because I have the pre-collision automated system so I won't crash into you. A lot of these problems are problems we've lived through before though either with the dawn of the internet or this one reminds me and we don't wanna be a little too car-centric but in the early 90s, late 80s there was an issue called busy cockpit for military aircraft which is you just had too much. Too many screens and too many little numbers. So how do you simplify the cockpit so the pilot could actually do what he was supposed to do and not manage the aircraft? We had one more. We have more. Quick introduction, my daughter lives in New York and she says a very popular app in Manhattan is an app that uses the video camera of your phone to show you the sidewalk just ahead of you. So as you walk down the street with your... I couldn't believe it but she's completely serious that that app exists and is widely used. Good afternoon. Doug Smith representing the Chesapeake Crescent Initiative. Question for the panel, the entire panel. In terms of the slow adoption of technologies that's going to be a concern. We're currently developing a safe and smart cities program. In fact, we'll be working with NIST in part of the Global Cities Challenge but the slow adoption of technology, you talk about the refresh rate of vehicles that's getting to be a longer period. You talk about the policy issues relative to citizens and their concern about privacy. That then also falls over to cities and to communities that are concerned about the cloud and the security of the cloud. What's the answer or is there an easy answer to the question of how do cities become smarter cities? Because it's a long complex project. So I think that's one of the challenges that the smart cities challenge and is trying to look at is what are the barriers that currently exist? What are the economics? What are the instrumentation and deployment issues and what are the longer life cycle issues that need to be addressed in order to fully realize a lot of this potential? I mean, you were mentioning earlier, what are the needed future skill sets and jobs and education pipes that need to be set up for this? I'm looking for a cryptographer, psychologist, data scientist. There's not a lot of them out there but these are the type of future skill sets that we need. What does the future IoT repair man look like? So there's potential for a large infrastructure shift to occur at a much larger level than just deploying a set of sensors and then looking at the data topographies. I've got to say something since you brought up the security of the cloud. Like any system, you can misuse a cloud platform but I will argue and many of my customers will come in here and tell you that they can build much more secure systems in a large scale, highly automated utility style computing platform and they could ever build for themselves when they were doing their own bespoke set of 100 servers or 1,000 servers sitting in a data center somewhere. We're operating at internet scale so we see internet weather patterns. We reach out to customers all the time and tell them, hey, there's something going on you need to know about which they didn't recognize for themselves. When we hire a security expert, the amount of servers that their skills impact is way larger factor of scale than when you hire that same security expert. The use of these very large scale systems, so this isn't so much a commercial plug as an industry plug. I'm plugging the idea of utility computing as a new way of doing computing. We really believe that security experts within their domain or within an application or an organization or an agency can focus on a much smaller set of the problem and they can write completely automated tools because everything in the infrastructure is an API. This is programmable infrastructure so there's no more people racking and stacking there's not that weekend where someone comes in and cross connects to the ethernet jack between the developer workstation and the server just to see if something, that just can't happen in highly scale automated systems. And so in general, I think we're gonna get more secure systems when you use large scale computing platforms. Now, again, you can misconfigure, you can misuse them. So there's still responsibility on the users to not configure them improperly but the actual base infrastructure itself, this is a big win and the analytics that you get from all that data. So again, we're seeing patterns and we're doing an analytics on very large scale patterns that are not visible to individual users of the platform and that redounds to the safety of the entire community. So I think cloud is not the security issue that's often perceived to be in fact, it's gonna be a win. We're getting close to the end so maybe we'll just start with the questions in the back and move up front. Raise your hand please, we've got two there and I think one in the front and then we're through. Hi, Josh Neu with the Center for Data Innovation. Hilary, I think you described it as a hysteria, the recent concern about people worried about their data being shared or collected and misused or abused. So with a number of things being ideally ubiquitous, everything from your car to a bridge you drive over to the street corner, how do you address the concerns from a regulatory perspective or a public image perspective of all this data being collected and shared and reused to end up returning value to the consumer and the citizen but with a lot of these devices they don't have human interfaces, they don't have a touch screen like your smartphone and you can't really collect, consent or deliver notification about their data being shared. How do you work around that? It's a pretty big question so if you can answer that, make my job easier. That's a good question for all the panelists too. I was like, I don't know that I have a unique answer on it, it's interesting. One of the things that I've been grappling with and I think it's a distinction, I don't know if it's a useful distinction but I think it's a distinction. And to me this element of choice and consent and that sort of thing may have more relevance in those things of which you have no choice, right? Or those things where you have a choice versus those things where you do not have a choice, right? But even then there's this element of sort of is it anonymous data, is it just aggregated data or is it identifiable data? For us when we were grappling with this as an auto industry we focused on data that is identifiable for the most part, not for the most part entirely. If it's anonymized or aggregated or de-identified it was not part of the calculus. And then there are pieces of vehicle data collection that are going to be optional to you. Like if you wanna be a probe on the WAIS system you can choose to be or if I wanna wear a Fitbit I'm choosing to wear a Fitbit versus some of these systems where there's not a choice. I don't know if it's a useful distinction but it's one of the ones that I've been sort of focusing in on is I've been thinking about these issues. I think you back in on a little bit. A lot of it starts with the education that I talked about earlier that is in the NSTAC report. People need to start understanding the amount of data they're generating. When I bought a Fitbit I didn't really think about all the different places that that data would be. Now I don't really care who has the data and how many steps I take. But when I actually, we did a report, we cemented it called quantified self came out last year that looked at all of the data and all the different places and the different vulnerabilities that it go through. Again if I'm talking about step count not such a big deal but when you start getting into other health characteristics that could be intercepted who knows how they're gonna be used. Until I think you have people being aware of it and raising concerns with it. It's gonna be hard to get traction to come up with solutions because there's not gonna be that outside force driving it. People really need to understand even what they're giving off with their phone. Who here has actually read an entire EULA when they clicked, you know, accept on an app? So I'm not banging EULAs but we need to think about that. We need to get people focused on actually our collecting data that's going out there. Hi, my question is about the connections between the devices and so it's twofold. The first is spectrum was brought up. Does the FCC have the capacity to manage the prioritization and the distribution of that spectrum? Are they thinking about this issue? And then the other thing is to what degree will the internet governance debate with ICANN play into the global nature of IoT? I'll take a stab at the first question at least. Shared spectrum use has been technically feasible for a long time. Some futurists have argued the FCC shouldn't exist at all because if you have the right technology, everybody can share all the spectrum and I think that's technically true although there's still the issues of enforcement and improper use and so forth. But there are these fair amount of capacity set aside for shared use and the technology knows how to hop around when it detects interference and find unused portions and any packet based systems also have a certain inherent resilience. So I don't personally think that's necessarily gonna be a big bottleneck in terms of solving some of these problems but then other panelists may have other perspectives on that. Well, I mean the issue of prioritization is being looked at. There's a couple of programs around the federal partnership for interoperable communications as well as the first net program looking at when we instrument these up, how do we understand and provide appropriate allocations to for example the first responders? So everyone's at the scene of the fire streaming that video back up to YouTube whereas the fire department would really like to stream it back to the inbound truck and so how do we ensure that there's proper allocation to places where potentially could provide the most good or should there just be a separate set for them all together? So this is still in a research slash development phase of discussion and deployment right now. Hi, we've talked a lot about capability but I'm wondering who's leading on the issues of data ownership through the life cycle of the data and liability. Who are the star lawyers that are helping you along the way to build that in just like you need to build security in? So I'm not a lawyer. I'm an engineer but this kind of dovetails with the question earlier and as from an engineering perspective we're very interested in, can we provide specific tangible privacy requirements that then can be used as with enough level of specificity so that privacy capabilities around redress, confidentiality, transparency, ownership, effective understanding of privacy risk, maybe with the EULA, maybe not, can all be actually built and designed into the system with the concept of privacy by design as we start to deploy these things out so then whoever is making those decisions at the policy stack can actually have that capability built in and designed with these systems as they go forward. So we're looking at it more at the capability and providing what references that we can to allow for the systems to at least have the capabilities to enforce or implement whatever the privacy policy happens to be. Chance of lifetime. Otherwise I'll do a poll as to how many are lawyers. Be a lawyer? Oh, well it's better than our usual rate. I have never practiced a day in my life though. Do I get a little credit for that? Yes. Can't say that. I would say that right now from what I've seen the IoT privacy legal work is really co-extensive with internet privacy generally. I haven't seen, and I may have missed it, but I haven't seen a breakout into let's look at IoT, let's look at the ownership of, you know, stick with my Fitbit with my step date as it moves around the world. I think that's coming, but all of this is, I feel like we're at the leading edge of a wave both technology and policy on this. Well in the early 90s there was a debate among economists and one famous economist said that we saw, information technology everywhere but in the productivity statistics. And the good news about that was he was wrong and the people buy things for a while. You don't see a benefit because they have to figure out how to use them, they have to innovate. And then you got a burst of economic growth that drove the U.S. economy for about a decade. So what I'm hopeful is if we can get this internet of things stuff right it may not be as distinguishable as the IT revolution but we can see a similar burst in economic growth and this was an appreciable increase to income. So with that, please, that's our goal here for us. Thinking of all the issues we've talked about, security, privacy, standards, international cooperation but I think we're on the path to maybe do this and I found this to be a really excellent panel. I don't know about you but I really appreciate them. Please give them a hand. Thank you.