NTIA’s next cybersecurity multistakeholder process will focus on Software Component Transparency. Participants will explore how manufacturers and vendors can communicate useful and actionable information about the third-party software components that comprise modern software and IoT devices, and how this data can be used by enterprises to foster better security decisions and practices.The next meeting is scheduled for November 6, 2018.
NTIA posted the video and transcripts from their July 19, 2018 meeting as well as the slides from the perspective sharing presentations. The presenters included members from CERT/CC, Oracle Security Alerts Group, Siemens Healthineers, CA Veracode, PTC, and New York Presbyterian.
Each presenter gave an 8-minute talk. The presentation from Josh Corman, the co-founder of the security group I Am The Calvary and the CSO of PTC, starts at 44:30. Here are his presentation slides. He discusses the Software Bill of Materials (SBOM) for medical devices.
Transcript (click to expand)
• Part 1
Thanks Chris. Now I would love to invite up Josh Corman who is the co-founder of security group I am the Calvary. He is the CSO of PTC.
I have a lot to cover so I will go fast. In general, I agree with most of what Chris just said there, but I want people to put this in the context of safety critical environments.
Even 5% exploitability when the consequences of failure could be [INAUDIBLE] physical cyber physical harm is a pretty large number, and if any of those are preventable harm, that's one of the reasons there is such a lean forward attitude from DHS for critical infrastructure, from FDA from the international community, so I am going to focus a bit more on the public safety of the human life.
I am the Chief Security Officer of PTC. I have a lot of software products. I have to produce software bill of materials for a lot of medical device, oil and gas, critical infrastructure customers I have. I have to eat my own dog food here.
To the point, I'm going to focus on some of the public safety human life where bits and bites meet flesh and blood from the Calvary, and more specifically, I was part of the congressional task force for healthcare cybersecurity, and one of our top recommendations which is being acted upon both by House Energy and Commerce and by HHS is they are actively rolling out a project to do a software bill of materials for all medical technologies.
That is happening irrespective of this effort. My hope is that the collective brain [INAUDIBLE] here can identify risks or issues or challenges or scoping levels that could make that better and more consistent across sectors. This is what we are really talking about.
I have a lot to cover so I will go fast. In general, I agree with most of what Chris just said there, but I want people to put this in the context of safety critical environments.
Even 5% exploitability when the consequences of failure could be [INAUDIBLE] physical cyber physical harm is a pretty large number, and if any of those are preventable harm, that's one of the reasons there is such a lean forward attitude from DHS for critical infrastructure, from FDA from the international community, so I am going to focus a bit more on the public safety of the human life.
I am the Chief Security Officer of PTC. I have a lot of software products. I have to produce software bill of materials for a lot of medical device, oil and gas, critical infrastructure customers I have. I have to eat my own dog food here.
To the point, I'm going to focus on some of the public safety human life where bits and bites meet flesh and blood from the Calvary, and more specifically, I was part of the congressional task force for healthcare cybersecurity, and one of our top recommendations which is being acted upon both by House Energy and Commerce and by HHS is they are actively rolling out a project to do a software bill of materials for all medical technologies.
That is happening irrespective of this effort. My hope is that the collective brain [INAUDIBLE] here can identify risks or issues or challenges or scoping levels that could make that better and more consistent across sectors. This is what we are really talking about.
• Part 2
Some of the objections you hear tend to be about secondary and tertiary potential uses of this, but we are talking about ingredients list. It's on all the food we eat; it's in every car you buy. This is a common practice for manufacturing.
Ingredients is an inventory of the parts. We are not even necessarily talking about nutrition labels, although, that could be a branch in a sequel for what's the attack surface, what's the ports being used, those kinds of things could also be valuable.
Is it patchable? Does this vendor have a [INAUDIBLE] disclosure program? There is a lot of FUD, I'm just going to call it FUD, but a lot of the top common objections, I think many of them will surface today, say it can't be done, but it's being done, or that we could never do it, we don't know what's in it, but they are often presenting those because there is legal license requirements for a lot of these open sources to declare what you are using.
This is a sample from Cisco's website, for example, of 107 different components they use and version numbers, often referred to as a blueprint for attackers, but they go a little further than they are obligated to do, but they are essentially already telling them on support documentation, not for defender use, but really just for license compliance.
I try to break this down into a three-tiered, three columned thing. The first one is the ingredients list, which is I believe what today's about, inventory, parts, lists. It's really important for one [INAUDIBLE] and suppliers. Most of my software will not be consumed directly by a consumer.
It's going to be consumed by a medical device manufacturer, and for them to be compliant with FDA requirements, I have to supply my subordinate partial SBoM so that they could provide their complete SBoM.
Ingredients is an inventory of the parts. We are not even necessarily talking about nutrition labels, although, that could be a branch in a sequel for what's the attack surface, what's the ports being used, those kinds of things could also be valuable.
Is it patchable? Does this vendor have a [INAUDIBLE] disclosure program? There is a lot of FUD, I'm just going to call it FUD, but a lot of the top common objections, I think many of them will surface today, say it can't be done, but it's being done, or that we could never do it, we don't know what's in it, but they are often presenting those because there is legal license requirements for a lot of these open sources to declare what you are using.
This is a sample from Cisco's website, for example, of 107 different components they use and version numbers, often referred to as a blueprint for attackers, but they go a little further than they are obligated to do, but they are essentially already telling them on support documentation, not for defender use, but really just for license compliance.
I try to break this down into a three-tiered, three columned thing. The first one is the ingredients list, which is I believe what today's about, inventory, parts, lists. It's really important for one [INAUDIBLE] and suppliers. Most of my software will not be consumed directly by a consumer.
It's going to be consumed by a medical device manufacturer, and for them to be compliant with FDA requirements, I have to supply my subordinate partial SBoM so that they could provide their complete SBoM.
• Part 3
This is a turtle stop stacked on turtles kind of a problem and one of the use cases should be those complex, multilevel SBoM type issues or supply chain type issues and the software supply chain assurance form that meets quarterly at Miter [PHONETIC] with DHS, DOD, GSA and others has been tackling this long, long time.
There's a lot of knowledge here. This is also stolen and borrowed from Demming supply chain from Toyota in the 40s. This was done to make more profitable, more reliable, high quality parts, not to make safer cars, just to make more profitable cars.
Some of the concerns do creep in, and I share those concerns around when you start the map to column B, which is what is the known vulnerabilities associated with that inventory list, that's where you could get a signal-to-noise ratio issue.
You could have customer complaints or questions, people expecting that they are all vulnerable, or that they want to see them all removed, and I think some education awareness working groups could really help here but essentially CVEs are not a great definitive list.
It's pretty poor, especially on Open Source, to be frank. This should be treated as potentially exploitable vulnerabilities not definitely exploitable. During an active attack to answer am I affected or where am I affected in a hospital context, this is an incredibly reliable mapping to at least shortlist from thousands of devices down to dozens of devices that might need further scrutiny.
And then third-party talent or third-party software could actually help with number three, which is which is the actual exploitable ones. Show some sort of substantiated claim that we are not using that.
Control flow is one, as Chris Wysopal pointed out, but a lot of the high-profile attacks, the one that actually started me on the path of concern about third-party Open Source software supply chain was July 2013. It was an [INAUDIBLE] vulnerability. It didn't matter how you were using it.
There's a lot of knowledge here. This is also stolen and borrowed from Demming supply chain from Toyota in the 40s. This was done to make more profitable, more reliable, high quality parts, not to make safer cars, just to make more profitable cars.
Some of the concerns do creep in, and I share those concerns around when you start the map to column B, which is what is the known vulnerabilities associated with that inventory list, that's where you could get a signal-to-noise ratio issue.
You could have customer complaints or questions, people expecting that they are all vulnerable, or that they want to see them all removed, and I think some education awareness working groups could really help here but essentially CVEs are not a great definitive list.
It's pretty poor, especially on Open Source, to be frank. This should be treated as potentially exploitable vulnerabilities not definitely exploitable. During an active attack to answer am I affected or where am I affected in a hospital context, this is an incredibly reliable mapping to at least shortlist from thousands of devices down to dozens of devices that might need further scrutiny.
And then third-party talent or third-party software could actually help with number three, which is which is the actual exploitable ones. Show some sort of substantiated claim that we are not using that.
Control flow is one, as Chris Wysopal pointed out, but a lot of the high-profile attacks, the one that actually started me on the path of concern about third-party Open Source software supply chain was July 2013. It was an [INAUDIBLE] vulnerability. It didn't matter how you were using it.
• Part 4
If you are using it, you were vulnerable, and it hit almost all the financial services companies. It was a real wake-up call for that sector. That was direct exploitation.
There's also chaining attacks; there's also things like deserialization attacks. One of those deserialization attacks was the Java JBoss one that I briefly mentioned which was a single deserialization plot on a single JBoss library that had [INAUDIBLE] for six years.
The FBI and InfraGard warned hospitals that they were being attacked. For anyone using this, they could not answer am I being affected and where am I affected. Could not, and; therefore, got hit anyhow. They shut down patient care for a week, diverted ambulances out of facilities, canceled patient procedures. It was pretty bad. And this is an isolated outage from [ INAUDIBLE] It became a foundational trigger for our task force.
I'm not going to tell you everything the task force found but in our comfortable truths [PHONETIC], we found 85% of hospitals don't have a single CISO or security personnel. They are defending really old stuff that's way past it's end of its life. They are over connected and reachable by the outside worlds, these flat networks, which means a single [INAUDIBLE] a single vice can take out patient care, and in the case of Hallowed [PHONETIC] Presbyterian, they didn't, in the case of WannaCry they did, but more importantly a typical medical technology has over 1000 CVEs in it, and we already know CVEs is a pretty terrible blind spot. One that we cited had 1400.
It only takes one to shut down the hospitals. These 5% numbers don't make me feel better. It takes one, and it's happened repeatedly. One of the things I hope Jennings talks about in his next one is during WannaCry, most of the hospital people I worked with on the task force had to call every single one of their vendors and beg to find out am I affected, am I affected? Do I need a patch? I'm blind. Help me out here.
Couldn't get answers or got false answers. Incredibly inefficient both for the people at the vending [PHONETIC] hospitals and the manufacturers who had to answer a flood of calls inefficiently and inaccurately. This transparency could be look-ups on, Oh we're not even using that library at all, let alone the wrong version.
In the context of something like Hallowed Presbyterian, we are less concerned about even someone doing ransomware, just Internet noise can hurt things. I'm going to skip this, but we had a former Team Poison anonymous guy found the Cyber Caliphate. [PHONETIC] What do you think he would do with a known vulnerability that knows nobody can patch?
There's also chaining attacks; there's also things like deserialization attacks. One of those deserialization attacks was the Java JBoss one that I briefly mentioned which was a single deserialization plot on a single JBoss library that had [INAUDIBLE] for six years.
The FBI and InfraGard warned hospitals that they were being attacked. For anyone using this, they could not answer am I being affected and where am I affected. Could not, and; therefore, got hit anyhow. They shut down patient care for a week, diverted ambulances out of facilities, canceled patient procedures. It was pretty bad. And this is an isolated outage from [ INAUDIBLE] It became a foundational trigger for our task force.
I'm not going to tell you everything the task force found but in our comfortable truths [PHONETIC], we found 85% of hospitals don't have a single CISO or security personnel. They are defending really old stuff that's way past it's end of its life. They are over connected and reachable by the outside worlds, these flat networks, which means a single [INAUDIBLE] a single vice can take out patient care, and in the case of Hallowed [PHONETIC] Presbyterian, they didn't, in the case of WannaCry they did, but more importantly a typical medical technology has over 1000 CVEs in it, and we already know CVEs is a pretty terrible blind spot. One that we cited had 1400.
It only takes one to shut down the hospitals. These 5% numbers don't make me feel better. It takes one, and it's happened repeatedly. One of the things I hope Jennings talks about in his next one is during WannaCry, most of the hospital people I worked with on the task force had to call every single one of their vendors and beg to find out am I affected, am I affected? Do I need a patch? I'm blind. Help me out here.
Couldn't get answers or got false answers. Incredibly inefficient both for the people at the vending [PHONETIC] hospitals and the manufacturers who had to answer a flood of calls inefficiently and inaccurately. This transparency could be look-ups on, Oh we're not even using that library at all, let alone the wrong version.
In the context of something like Hallowed Presbyterian, we are less concerned about even someone doing ransomware, just Internet noise can hurt things. I'm going to skip this, but we had a former Team Poison anonymous guy found the Cyber Caliphate. [PHONETIC] What do you think he would do with a known vulnerability that knows nobody can patch?
• Part 5
In the last minutes here, I just want to point that people claim this hasn't been done, it can't be done. For about six years now, the financial services sector for the software they write and self-consume have been doing software billable materials mostly as a productivity boost.
There's the entire rich market called Software Composition Analysis with many vendors and free and open source alternatives to those vendors. Typically, you will see 106 components on average, about 23% of them by volume have a known vulnerability associated, and even if one or two of them is vulnerable, those could lead to significant harm.
The triggering point wasn't Heartbleed, it was actually prior. It was July 2013. Apache Struts hit most banks, huge wake-up call, so people started paying more attention to open season on open source. There has been a bunch of academic work.
Dan Geer published something with me in 2014 in Usenix. There's been some economic analysis of that avoidable harm at the head waters [PHONETIC] at the manufacture of what is significant downstream breach costs, patent emergency patch costs, Frenzies.
Underwriters Laboratories has taken on this with their cyber assurance program which is now two or three years old. Several parts of the US government have touched on this and advocated for it including DHS through safety critical IoT principles. The Department of Transportation and the Auto-ISAC is fairly on board with this because it is very congruent with their normal physical supply chain management.
The Presidential Commissions was calling for nutrition labels to enable more informed free-market choice, and the question is going to be, how much granularity. The White House said known but unmitigated vulnerabilities are among the highest risk to the federal government, and they are specifically referring to 10-year-old known vulnerabilities found frequently.
Here is the Commissioner of the FDA has also been calling out and announced yesterday their intentions to roll this out at least for medical devices. My intention and hope is that this group can help make sure that that's a better program deployed earlier and more consistent across things because as a software producer, I don't want to have 10 different standards for 10 different sectors. Here is the lead up on the board, some workstreams you might want to consider, but I want this to be done better with the collective might and intelligence of this room. Thanks.
There's the entire rich market called Software Composition Analysis with many vendors and free and open source alternatives to those vendors. Typically, you will see 106 components on average, about 23% of them by volume have a known vulnerability associated, and even if one or two of them is vulnerable, those could lead to significant harm.
The triggering point wasn't Heartbleed, it was actually prior. It was July 2013. Apache Struts hit most banks, huge wake-up call, so people started paying more attention to open season on open source. There has been a bunch of academic work.
Dan Geer published something with me in 2014 in Usenix. There's been some economic analysis of that avoidable harm at the head waters [PHONETIC] at the manufacture of what is significant downstream breach costs, patent emergency patch costs, Frenzies.
Underwriters Laboratories has taken on this with their cyber assurance program which is now two or three years old. Several parts of the US government have touched on this and advocated for it including DHS through safety critical IoT principles. The Department of Transportation and the Auto-ISAC is fairly on board with this because it is very congruent with their normal physical supply chain management.
The Presidential Commissions was calling for nutrition labels to enable more informed free-market choice, and the question is going to be, how much granularity. The White House said known but unmitigated vulnerabilities are among the highest risk to the federal government, and they are specifically referring to 10-year-old known vulnerabilities found frequently.
Here is the Commissioner of the FDA has also been calling out and announced yesterday their intentions to roll this out at least for medical devices. My intention and hope is that this group can help make sure that that's a better program deployed earlier and more consistent across things because as a software producer, I don't want to have 10 different standards for 10 different sectors. Here is the lead up on the board, some workstreams you might want to consider, but I want this to be done better with the collective might and intelligence of this room. Thanks.
No comments:
Post a Comment