President Trump’s historic EO 13806 provided DoD and its interagency partners a unique opportunity to assess the manufacturing and defense industrial base – one of the most critical assets to our national security. The work conducted by the over 300 members of the DoD-led Interagency Task Force lays the groundwork for important actions, mitigations, and ongoing monitoring that will result in America’s ability to continue supporting a secure, robust, resilient, and ready industrial base.
Current Efforts
The DoD-led Interagency Task Force recognizes and supports ongoing efforts to address the challenges identified in the EO 13806 assessment, including:
Increased near-term DoD budget stability with the passage of the Bipartisan Budget Act of 2018, providing stable funding through FY2019
Modernization of the Committee on Foreign Investment in the U.S. and investigations under Section 301 of the Trade Act of 1974 into Chinese intellectual property theft, to better combat Chinese industrial policies targeting American intellectual property
Updates to the Conventional Arms Transfer policy and unmanned aerial systems export policy to increase U.S. industrial base competitiveness and strengthen international alliances
More Current Efforts continue in the report and are followed by Future Efforts and Recommendations.
Here is a statement from the White House on the report.
Interagency Task Force in Fulfillment of Executive Order 13806
= "Assessing and Strengthening the Manufacturing and Defense Industrial Base and Supply Chain Resiliency of the United States" https://t.co/NJTU8uQuL7pic.twitter.com/9sLyfVsGJN
The National Telecommunications and Information Administration's (NTIA) first meeting on Software Component Transparency was held on July 19, 2018. From NTIA:
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.
• 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.
• 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.
• 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?
• 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.
The U.S.-China Economic and Security Review Commission published a research report on supply chain vulnerabilities:
Summary: The U.S.-China Economic and Security Review Commission released a report entitled Supply Chain Vulnerabilities from China in U.S. Federal Information and Communications Technology, prepared for the Commission by Interos Solutions, Inc. The report examines vulnerabilities in the U.S. government information and communications technology (ICT) supply chains posed by China, and makes recommendations for supply chain risk management.
Here are the recommendations from the report:
• Embrace an Adaptive Supply Chain Risk Management (SCRM) Process
• Centralized Federal ICT SCRM Efforts
• Link Federal Regulations to Appropriations
• Promote Supply Chain Transparency and Partnership with Industry
• Craft Forward-Looking Policy
• Embrace an Adaptive Supply Chain Risk Management (SCRM) Process
Federal ICT modernization efforts have increased reliance on the private sector and commercial off-the-shelf (COTS) products. These new products have increasingly complex, globalized, and dynamic supply chains, many of which include commercial suppliers that source from China at multiple points within a single supply chain. These supply chains change over time as companies develop new technologies and partner with new suppliers, and effective SCRM policies must be able to adapt as well.
Nefarious actors linked to China have targeted the networks of private sector entities and private sector government contractors in order to obtain sensitive government information and to exploit vulnerabilities within federal information systems. Thus, weaknesses in the networks of industry partners pose a threat to the U.S. government and U.S. national security.
Defending against supply chain attacks by nefarious actors linked to China requires communication and collaboration with private sector actors. The National Institute of Standards and Technology (NIST) has been effective in partnering with the private sector to produce high-quality, implementable standards to improve supply chain security and cybersecurity of ICT systems, including the widely adopted NIST Cybersecurity Framework.
Although NIST has been effective in these efforts, supply chain controls developed by NIST apply only to “high-impact” federal information systems.4 Future work by NIST could include expanding supply chain standards to a broader range of federal information systems, including systems operated by private sector contractors.
Partnering with industry also means learning from experience with efforts such as the Bush-era Comprehensive National Cybersecurity Initiative (CNCI). The CNCI’s effectiveness was limited by the classified nature of its deliberations and decisions, which prevented the U.S. Department of State and the National Cyber Security Center from engaging with outside organizations, including the private sector.
Policymakers must empower rather than hinder the efforts of successful collaborative entities such as NIST and keep as much discussion of the supply chain threat as possible in the unclassified public sphere. These steps will ensure that new SCRM policies can be adaptive, be collaborative, and achieve buy-in from all relevant parties.
• Centralized Federal ICT SCRM Efforts
The U.S. government lacks a consistent, holistic SCRM approach. Additionally, most federal SCRM-related intelligence gathering activities are people based rather than technology based. This makes it difficult for federal SCRM programs to address the global threat comprehensively, or to scale as demand increases. The conflicting and confusing laws and regulations result in loopholes, duplication of effort, and inconsistently applied policies.
Congress and the Executive Branch should encourage information sharing and the consolidation of federal SCRM leadership to optimize collection and dissemination efforts. Centralized leadership for SCRM would need to be resourced and staffed appropriately and tasked with vetting to a prescribed level the suppliers and value-added resellers of products entering the federal IT network.
The Office of Management and Budget (OMB) could, through modifications to Circular A-130,6 assign centralized SCRM authority to the General Services Administration (GSA), the U.S. Department of Homeland Security (DHS), or another federal agency. This SCRM center would provide comprehensive and authoritative data and continuous monitoring, which would reduce the need for agency-specific SCRM and allow agencies to focus their efforts on particular configurations and implementation situations; how agencies use technology directly relates to how they apply risk mitigations.
Last, such an office would need to function in the unclassified world, while at the same time having direct connections and reach-back authority into the classified environment to ensure it remains in alignment with known threats. As illustrated by the experience of the CNCI, the relationship should not be reversed and come entirely under classified control.
• Link Federal Regulations to Appropriations
Along with modifications to policy—such as Circular A-130—Congress should tie policy revisions to a funding strategy that ensures federal agencies take action in ways that are auditable. One recommendation is to expand the Wolf Provision, or Section 515 of the Consolidated and Further Continuing Appropriations Act, to apply to all federal agencies and entities. A near-term opportunity is to tie the SCRM requirements of this regulation to agency funding for the Modernizing Government Technology Act of 2017 in ways that require a SCRM program review for new ICT investments and modernization efforts.
One improvement to the provision would be to require agencies to annually present (1) information about their established SCRM program, (2) the activities that have taken place within that program, and (3) the mitigations used. These annual reports will help build a best practices library for all federal government entities, increasing information sharing and awareness of evolving risks. The current reporting is compliance oriented and does nothing to share information or increase the security posture of federal ICT networks.
• Promote Supply Chain Transparency and Partnership with Industry
Supply chain transparency increases the security of the federal ICT supply chain by enabling the federal government to source responsibly and securely, and by improving the government’s ability to respond to, and reduce the impact of, cybersecurity incidents in an environment where supply chain attacks are ongoing.
Directly in relation to the impact on national security, the federal government should promote the public listing—or at least the disclosure to the government customer—of federal ICT providers and primary or tier-one suppliers in line with actions already taken by companies such as Dell, Hewlett-Packard (HP), and Microsoft as part of their corporate responsibility efforts.
The government should also push for transparency on the part of all suppliers within its own supply chain according to the level of risk management rigor required (not all programs and suppliers present the same level of risk and therefore this level of transparency may not be needed). This information does not always need to be publicly released, though audit measures should be in place to ensure the transparency exists.
In taking these measures, policymakers should learn from previous supply chain transparency efforts, such as Section 1502 of the Dodd-Frank Wall Street Reform and Consumer Protection Act of 2010, which required some companies to document their suppliers of “conflict minerals” in order to decrease violence in the Democratic Republic of the Congo (DRC) by limiting U.S. procurement from actors fueling conflict in the DRC.
By partnering with industry and sharing information, the government customers and industry will have increased awareness of risks present in multi-tiered supplier relationships, as well as potentially effective mitigations that are already in place.
• Craft Forward-Looking Policy
Increasingly, any ICT component’s physical structure pales in importance compared with the firmware and software operating within in it. Future risks will involve software, cloud-based infrastructures, and hyper-converged products rather than hardware. A vendor’s, supplier’s, or manufacturer’s business alliances, investment sources, and joint research and development (R&D) efforts are also sources of risk that are not always covered in traditional SCRM. Identifying these risks and addressing them creatively as part of the adaptive approach to supply chain risk management will be important to the success of federal policy efforts.
New report just released, entitled "Supply Chain Vulnerabilities from China in U.S. Federal Information and Communications Technology." Read it here: https://t.co/bpIiGQE2c0#supplychain#china
Jennifer Bisceglie testifies for a Homeland Security Hearing
Source: www.hsgac.senate.gov
Jennifer Bisceglie testified for the Senate Homeland Security Committee hearing "Evolving Threats to the Homeland" on September 13, 2018. She specifically reviews supply chain risk management (SCRM) as it relates to information and communications technology (ICT), a security domain covered by her company Interos.
Her company recently supported the US China Economic and Security Review Commission with regards to their report on supply chain vulnerabilities from China "which outlines several recommendations, the most important being that the U.S. establish a “National Strategy for Supply Chain Risk Management (SCRM) in U.S. ICT” with supporting policies, so that the Nation’s security posture is forward-leaning vs reactive and based on incident response."
She organizes her written testimony to address six key areas related to the report and to the topic of the hearing. Here are a few of the topics she addresses:
1. A brief assessment of the emerging economic and national security risks from next generation connectivity and devices (particularly the IoT and 5G networks) for the U.S. with specific reference to the risks posed by other economies such as China, Russia and other sensitive countries. What additional risks, if any, does use of IT, standards, and/or equipment developed in sensitive countries pose to U.S. security? Are existing authorities and regulations adequate to address these challenges?
Software supply chain attacks will become easier – and more prevalent - as developing technologies such as fifth generation (5G) mobile network technology and the IoT exponentially increase the avenues for attack.1 [,,,] Relevant to the Report, increasing IoT installations will expand the attack surface of federal ICT networks while decreasing the time required to breach them, yet to date, the time required to detect breaches is not decreasing. The responsibility of both the public and private sector in improving their approach to risk awareness and management in the commercial technology supply chain cannot be overstated.
Taiwanese based-company NUUO who makes camera firmware has recently issued a patch for a zero-day vulnerability named Peekaboo (CVE-2018-1149, CVE-2018-1150) that exploits IoT video recorder software. The vulnerability was discovered by Jacob Baines, a senior research engineer at Tenable. From Tenable's blog on CVE-2018-1150 specifically:
If a file named /tmp/moses exists, the backdoor is enabled. It permits the listing of all user accounts on a system, and allows someone to change any account’s password. This would, for example, permit an attacker to view the camera feeds, view CCTV recordings, or remove a camera from the system entirely. This vulnerability has a CVSSv2 Base Score of 4.0 and a Temporal Score of 3.2, and is rated Medium severity.
This is a very odd artifact. We weren’t able to determine if it’s leftover development code or if it was maliciously added. To be able to activate and utilize the backdoor, an attacker would need to be able to create the file “/tmp/moses,” so the attack would require some form of access or need to be combined with another exploit. Its existence and lack of obfuscation in the code is the real mystery.
#TenableResearch has discovered a critical vulnerability named Peekaboo permitting RCE in IoT network video recorders for video surveillance systems. Learn more on the blog: https://t.co/a1O3GyLQCB
The lawyer who is representing the 220,000 plaintiffs in the 2015 Jeep hack class action lawsuit, Ijay Palansky, presented at Black Hat USA 2018. He outlines the potential pathways of harm for the IoT including DDoS attacks, IoT ransomware, data breaches, privacy-related events, potential for cyber-physical, etc. He offers that there are currently few precedents or standards of care for how the law applies to tech and the complex IoT supply chain ecosystem. Here are his presentation slides and abstract:
Legal Liability for IOT Cybersecurity Vulnerabilities
There has been much discussion of "software liability," and whether new laws are needed to encourage or require safer software. My presentation will discuss how -- regardless of whether new laws are passed -- a tidal wave of litigation over defective IoT cybersecurity is just over the horizon.
The presentation will focus on a well-known example: Charlie Miller and Chris Valasek's 2015 Jeep hack. I'm lead counsel in the ongoing federal litigation over the cybersecurity defects Charlie and Chris exposed, and that are shared by 1.4 million Chrysler vehicles. As far as I know, our case is one of the first, and the biggest, that involves claims that consumers should be compensated for inadequate cybersecurity in IoT products.
This case is the tip of the iceberg. IOT products are ubiquitous, and in general their cybersecurity is feeble, at best. In the event of a cyberphysical IoT hack that causes injury, there are established legal doctrines that can be used to impose liability every company involved in the design, manufacturing, and distribution of an exploited IoT device or even its cyber-related components. Such liability could be crippling, if not fatal, for organizations that don't know how to properly handle and prepare for potential lawsuits.
Taking steps to minimize legal exposure before an accident happens or a lawsuit is filed—in the design, manufacture, product testing, and marketing phases of an IoT product—can be the difference between life and death for IoT companies. Knowing what steps to take and how to take them requires an understanding of the core legal principles that will be applied in determining whether a company is liable.
The July 11, 2018 hearing was held by the U.S. Senate Committee on Commerce, Science, and Transportation and was convened by its Chairman U.S. Sen. John Thune (R-S.D.).
Witnesses:
Ms. Donna Dodson, Chief Cybersecurity Advisor and Director of the National Cybersecurity Center of Excellence, National Institute of Standards and Technology, U.S. Department of Commerce
