Posted by Synopsys Editorial Team on September 15, 2017
Fault Injection is a podcast from Synopsys that digs deep into software quality and security issues. This week, hosts Robert Vamosi, CISSP and security strategist at Synopsys, and Chris Clark, principal security engineer at Synopsys, interview Ken Modeste of UL at this year’s codenomi-con 2017, held at the end of July at the House of Blues in Mandalay Bay Resort and Casino in Las Vegas. Modeste talks about his work on the UL Cybersecurity Assurance Program.
You can always join the discussion by sending us an email at email@example.com.
Robert Vamosi: This is Fault Injection. I’m Robert Vamosi, CISSP and security strategist here at Synopsys.
Chris Clark: And my name’s Chris Clark. Welcome back, everybody. We have a very special guest with us tonight: Ken Modeste from UL. Ken, do you want to introduce yourself?
Ken Modeste: Hey, my name is Ken. Thanks for having me.
Chris: What do you do over at UL?
Ken: I do a lot, you know, but at the end of the day, a big part of what I do is driving UL’s mission. And UL’s mission is about public safety, and the biggest thing that affects public safety for this century is security.
Chris: Security. A lot of activity around the security space. Well, you guys have done something really interesting: the CAP program.
Robert: Want to explain what CAP stands for?
Ken: CAP stands for Cybersecurity Assurance Program. What that really is is looking at how we can solve cyber security in this century. Start with science. Science is based off of standards and specifications. So we worked on developing a series of standards to start an assessment of cyber security in products today.
Chris: This is the 2900, right?
Ken: This is the 2900.
Ken: They have different flavors, different volumes of them, and we published most of them at the beginning of last year. Recently, about 2 weeks ago, we finally published the ANSI UL, which is the U.S. version or the U.S. national standard copy of this. So now it’s a U.S. national standard. We hope in a couple of weeks to do the same for Canada—it takes a while with translations, it has to be in both English and French—which is a big milestone to reach, because now it’s a national standard that comes out of both UL ANSI and SEC in Canada.
Chris: Very challenging. I bet that had to be a lot of work. Having worked on standards committees, I know there’s a lot of challenges getting that type of work out.
Ken: A lot of work, and then also trying to address one of the fundamental things—you having your experience working on standards—is doing it in the right time, not taking 5 or 10 years. So our first draft we started in summer of 2015. It got published in March of 2016. And we just published the ANSI national standard version 2 weeks ago.
Chris: Very cool. Now there’s a couple of aspects to the 2900 standard: 2900-1, 2900-2, and 2900-3. What does each one represent?
Ken: So you have to really look at cyber security as a multitenant type of way of addressing the problem. Look at it from a component perspective. What’s the most prolific component with any product today that generates the most security incidents? Software. So the first version, UL 2900-1, looked at how you would address software, whether it’s in a television, whether it’s in a toothbrush, whether it’s in a car part, the braking system, wherever. And then UL 2900-2, the series, started taking 2900-1, the core component for software, and started focusing it for specific domains—medical, industrial control systems. We have two more that we’re developing, which is building automation and life safety, like fire alarm systems, smoke systems. And then the third one is 2900-3, which now starts looking at the organizations, the processes. Who are designing these systems? Who are building these systems, manufacturing them? The entire supply chain from start all the way to decommissioning, the asset owner, the system operator. So it provides a holistic way of looking at cyber security, and it also doesn’t deeply couple them or tightly couple them, so any particular person can use what they need at that particular time.
Chris: Very interesting. So when we talk about some of these standards, is the idea of, let’s say, 2900-1 that we want to make cyber security certification accessible for not only critical components but also commercial components? Or is the idea a little bit different?
Ken: The idea is the standard provides guidance to industry on how to go ahead developing products with consideration of security. One of the outcomes or the deliverables of that could potentially be a certificate. And that’s one of the things we also do. Does it mean that you will certify your toothbrush if it’s an IoT? Probably not. But you might want to have your infusion pump certified. Or you might want to have that new factory plant programmable logic controller. Or you might want to have your tire pressure sensor system, as an example. So I think it really is now up to the industry and the domains that they start looking at it and start seeing, where do they see the right value for the manufacturer base, for the clients that are purchasing it, for the industry as a whole? And certification offers an ability for someone—a third party like UL, a trusted third party like UL—to come in and say, “We have validated and vetted that this organization follows these standards and complies with the requirements.” They are very valuable in some industries, and in some you probably don’t need it. The guidance is good enough.
Chris: Teddy bears with microphones in them, maybe. So you know that kind of brings up an interesting topic.
Ken: That’s a good example.
Robert: It is. Great segue there, Chris. I like that.
Chris: Everyone’s talking about it. It’s a critical thing. One of the things that we hear quite often, though, is “Security’s expensive. I don’t want to do it for everything, because it takes a lot of time. It brings a lot of extra burden from a development perspective.” I have a very different view on that. But could you comment on how 2900 may affect or may not affect that?
Ken: Security is expensive. Safety’s expensive too, right? If you buy a device today—a smartphone, a smart car, a microwave, a refrigerator—do you expect it to catch on fire?
Chris: No, you don’t.
Ken: Electrocute yourself?
Robert: Well, not if it doesn’t have UL label on it.
Ken: But you expect it, right? You expect it to have this safety. So you as a consumer have demanded that that’s something that you expect from the product. We as consumers today aren’t demanding as much when it comes to cyber security. We’re starting to. So what you’re starting to see in critical infrastructure, medical, SCADA systems, ICS systems, the asset owners or the procurers are starting to say, “Hold on. Wait a minute. I am expecting this now because that’s something that I see has significant value.” So is it expensive or is it not expensive? There’s always some added component from testing and certification—and even design—that adds to the true lifetime costs of a product. But what’s the ROI that a manufacturer would have that they’re producing products that meet the requirements of their consumer, the person who’s buying it? And if the consumers are starting to say, “This is important to me,” then it’s not expensive. It becomes a need.
Robert: So what becomes the tipping point for the consumers to start to expect security, as opposed to “I don’t want my toaster to go up in flames tomorrow morning”?
Ken: I think we’re getting there.
Robert: We’re getting there. These, you know, stunt hacks that go on, these celebrity things that happen that are in the news? Or is it more an awareness that “Wow, all this stuff is in my personal life, and I depend on my insulin pump. I depend on my pacemaker.”
Ken: I think the whole concept of IoT starting from 2007, when you have sort of an advent or an explosion of smart devices. Now that you have IoT, more and more of what consumers have today are starting to impact what they’re requesting. So where do you see that impetus coming from to demand that? It’s starting to come in certain areas. Medical, the hospitals and medical systems, after the attempts that happened in the last couple of months in Europe, are starting to say, “This is fairly important.” Like at the ending of last year, the Mirai botnet that had a devastating effect on the Northeastern Seaboard—you couldn’t get your Netflix, you couldn’t get your Amazon, and it’s related to a camera that’s in a particular retail store down the street. You’re going to start to ask that. So going back to the toothbrush, do I think somebody would care if somebody knows that I brush my teeth and it took 20 strokes instead of 30? Probably not. But if that toothbrush allows somebody to turn on that nanny cam with the camera…
Robert: Because it’s on the network.
Ken: Because it’s on the network, you’re going to start seeing consumers react. So the proliferation of IoT devices and the consumption of it is starting to have that effect. Will it happen today or tomorrow? I think you see a good progression, and hopefully people like myself and the early adopters with the smart locks and stuff in their homes will start seeing some trends that will start seeing security embedded in there.
Chris: You bring up an interesting point. What I’m excited about with 2900 is 2900’s evolving very quickly. You kind of touched on this earlier. Software is changing every day. The standards have to evolve with those software changes. What have some of the changes been with the 2900 series?
Ken: It’s interesting. The differences between the first and the second were more about lessons learned on how to do the testing. We went through a pilot phase, and as we went through that pilot phase, we learned some things that weren’t that major. But what we’re starting to see now is a lot of requests that are coming in on other things, additional things. People are asking about hardware. People are asking about cloud systems, because everything is in the Cloud. You know, like can 2900 deal with the Cloud? Or is there some additional requirements that you have to add to it? People are asking about heavyweight and lightweight crypto: What is the value and the need for that? And finally, code analysis. I think you’re starting to see now there’s a lot in there about code analysis and actually scanning and looking for weaknesses in the source code. It’s driving some changes within the industries, so now you’re having some additional requirements coming out of that. But the no. 1 thing that I’m pleasantly surprised about is risk management. That’s the biggest thing, the biggest impact that I’m seeing, that you will see some significant additions coming in the next release, because there’s more vendors that are asking, “Hey, we need help. We need some more guidance there. Provide us with some more documentation or capabilities so that we can start addressing it across the board in our organization.”
Chris: Very cool. So, one, I want to thank you for spending time with us going through this.
Ken: You’re welcome. Anytime for you, Chris.
Chris: Well, he says that…so thank you again for joining us at CodenomiCON 2017, and enjoy Black Blat—oh my goodness, I’ve already been talking too much—Black Hat. That’s coming up. Thank you again, Ken.
Robert: And be sure to contact us on the email address that we have: firstname.lastname@example.org. Yes, Ken?
Ken: I was going to say thanks for having me, and I will say it little bit clearer: at Black Hat 2017.
Chris: Thank you, everybody.
Robert: Thank you.
Get the latest Software Integrity news, thought leadership, and more.