Andreas Kuehlmann addresses Future Connected Cars on May 12, 2016.

On Thursday, Andreas Kuehlmann, Senior Vice President and General Manager for Software Integrity at Synopsys, was one of the speakers at the Future Connected Cars conference in Santa Clara, California.

In his talk, Kuehlmann addressed how automakers can avoid costly recalls or brand damage through a process called “software signoff.” There exists within the hardware domain an established signoff process where a part is tested before it is accepted into the general supply chain. The same is not yet true with software, where up to 90 percent of the software may be sourced from outside an organization. This can include generally accepted open source code and third-party code. Having a procedure to test and audit this code throughout the lifecycle is essential.

Additionally Kuehlmann talked about self-regulation within the automotive industry. He mentioned a new working group from SAE that supports self-governance. The working group, TEVEES18A1 Cybersecurity Assurance Testing Task Force, is lead by Mike Ahmadi, Director of Critical Systems Security at Synopsys.

Future Connected Cars was held alongside this year’s Internet of Things World and AppsWorld at the Santa Clara, California, convention center. A sister event, Connected Cars 2016, will be held June 28 June – 30 at the Olympia Grand in London.

Earlier in the day, Chris Clark, Principal Security Engineer for Global Solutions at Synopsys, demoed the Synopsys Software Integrity Platform to attendees in the exhibit hall.

Chris Clark demos the Synopsys Software Integrity Platform at Future Connected Cars 2016

In a related Code Review podcast, Clark talked with host Robert Vamosi, CISSP and Security Strategist at Synopsys, about software security, the connected car, and the value of cybersecurity evaluation requirements and audits.

With an eye toward use in automobiles, the electric grid, and emergency response teams, the National Institute for Science and Technology (NIST) proposes how organizations can incorporate time-tested security design principles and concepts into these systems from concept to completion in a new publication.

Originally available in 2014, Special Publication 800-160: Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems is based on the international ISO/IEC/IEEE Standard 15288 for Systems and Software Engineering. The new public draft aims to merge the cyber and physical world best practices.

“The systems security engineering considerations in NIST SP 800-160 give organizations the capability to strengthen their systems against cyberattacks, limit the damage from those attacks if they occur, and make their systems survivable,” NIST Fellow Ron Ross said in a blog.

Of interest to software developers is Appendix J “Software Security And Assurance: Applying Security Fundamentals To Achieve More Trustworthy Software” discusses security controls for software assurance.

A copy of NIST SP 800-160 is available as a download PDF here. Appendix J will be made available separately until inclusion in the final document, once approved. At press time Appendix J was not yet available.

“The key to reducing the risk to our critical infrastructure is to build ‘trustable‘ systems on a foundation of systematic and accepted engineering principles,” said Robert Bigman, a cybersecurity consultant at 2BSecure and former Central Intelligence Agency chief information security officer.

“NIST SP 800-160 will become the de facto standard for integrating ‘trustability’ into the design, development, deployment and operation of systems used both within government and commercial critical infrastructure industries,” he said.

A draft of ISA 62443-4-1 has been approved and now heads to IEC for final confirmation.

Known officially as ISA-62443-4-1 Security for industrial automation and control systems Part 4-1: Secure product development life-cycle requirements, the document is part of a certification program which assesses a supplier’s product development lifecycle processes for industrial automation control systems. The program offers increasing levels of development lifecycle security assurance. This document determines whether the assurance applies to development of components, systems or both; and the scope of products to which the organization applies the process (which may be all products).

Founded in 1945, the International Society of Automation (ISA) is a nonprofit organization. It currently has more than 40,000 members worldwide. The organization primarily creates standards for automation.

A related organization, International Electrotechnical Commission (IEC), creates International Standards and Conformity Assessment for all electrical, electronic and related technologies.

Of interest for software testers are section 8.2.1 (c) Static Code Analysis (SCA), which states that this testing shall be done if testing exists for that language and/or if the software has changed. A separate section addresses testing for third-party software.

Section 9.4 SV-3 covers vulnerability testing covers fuzz testing and network traffic load testing and capacity testing, attack surface analysis, and black box known vulnerability scanning. For software composition analysis on all binary executable, the following types of problems at a minimum:

(1) known vulnerabilities in the product software components,
(2) linking to vulnerable libraries,
(3) security rule violations, and
(4) compiler settings that may lead to vulnerabilities.

This standard does matter. ISA and IEC standards are often mandated by law in Europe for example.

.

With yesterday’s full release of details about the much-discussed Badlock bug, one of the CVEs identified as related is attributed to Synopsys.

CVE-2015-5370 includes within its credits a call out for Jouni Knuutinen from Synopsys for “discovering and reporting this security bug using the Defensics product.” Defensics works by automating the creation of malformed input and then identifying abnormalities within the results. The Synopsys tool is also credited with discovering the Heartbleed OpenSSL bug two years ago, among many other high profile vulnerabilities.

According to the release, versions of Samba from 3.6.0 to 4.4.0 inclusive are vulnerable to denial of service (DoS) attacks in the DCE-RPC client and server implementations. This can lead to crashes and high CPU consumption. In addition, there are errors in validation of the DCE-RPC packets that can lead to a downgrade of a secure connection to an insecure one.

The advisory states that this vulnerability is unlikely to be exploited, however, if it is, there is a chance for a remote code execution attack, which may gain root access for the attacker, against the client components used by smbd and winbindd, and tools like net, rpcclien, and others.

On Tuesday, Samba issued versions 4.4.2, 4.3.8, and 4.2.11 as security releases to correct the defect.

The Badlock Bug announcement raises a few really interesting issues. The first and most important issue that we shouldn’t lose sight of is that software vulnerabilities, especially ones that affect widely used open source components like Samba, pose a very real threat. Finding these bugs by integrating security testing into the development process and throughout the software lifecycle is important. The best case scenario is eliminating them before software is released, but realistically you can’t catch them all. When vulnerabilities are discovered in the wild, they often require rapid and pervasive remediation efforts to preempt attacks so timing is critical.

The second and perhaps more fiercely debated issue right now is responsible disclosure. Security researchers and vendors have a responsibility to notify the appropriate stakeholders when they find a vulnerability so it can be addressed before details are revealed to public. In this case, it appears that SerNet began working with the Samba Team and Microsoft to resolve the problem some time ago. What’s interesting is that they made a big splash by branding the bug and going public with some of the details almost three weeks before the official disclosure and patches were scheduled to be released. A lot of the criticism in security circles today is that this announcement is a marketing stunt that not only challenges hackers to start poking around but gives them a pretty good idea where to start looking.

There were people who criticized Codenomicon, now part of Synopsys, for giving Heartbleed a name and a logo when we independently discovered it back in April 2014, so this situation feels somewhat familiar. The difference, of course, is that we didn’t make an announcement until after OpenSSL issued a patch and word had already started to spread from other sources. In our case, the clever name and logo definitely contributed to how much attention the bug received, especially among people outside the security profession. Our company got a lot of exposure too, but our efforts helped educate a lot of people and ultimately led to a greater awareness around software security. That’s a good thing. Branding the Badlock Bug may have a similar effect, and I hope that’s the case.

On Tuesday, Synopsys and Underwriter’s Laboratory (UL) announced they have collaborated to elevate transparency and confidence in the security of network-connectable devices through the creation of the UL Cybersecurity Assurance Program (UL CAP). The new certification enables device manufacturers to demonstrate diligence and provide security assurance to downstream customers and end users.

The UL CAP is an independent third-party testing and certification program for network-connectable products and software components, including industrial control systems (ICS), medical devices, in-vehicle software systems and other IoT devices.

This new certification program verifies compliance with UL2900, a series of standards developed by UL with input from industry stakeholders. UL2900 validates that a product offers a reasonable level of protection against cybersecurity risks that may result in unintended or unauthorized access, change or disruption.

The White House recently recognized UL CAP in the Cybersecurity National Action Plan as a key initiative in the coordinated effort between the Department of Homeland Security (DHS) and the private sector to enhance the Nation’s critical infrastructure security and resilience.

How to prepare for UL CAP certification with our Software Integrity Platform

Software security testing tools from Synopsys are designated for use in the UL Cybersecurity Assurance Program. Device manufacturers and component suppliers can proactively prepare for UL CAP certification by using the same tools as UL. Specifically, UL’s test lab uses Synopsys software testing tools to evaluate products against the following requirements:

• Known Vulnerabilities and Exposures – Synopsys’ Protecode™ solution is used to scan a product’s software executables and libraries for known vulnerabilities and exposures.
• Software Weaknesses – Synopsys’s Coverity® static code analysis tool is used on all source code that is made available to the laboratory by the vendor to look for software weaknesses as identified in the SANS Top 25 and OWASP Top 10.
• Robustness Testing – Synopsys’ Defensics® solution, the fuzz testing tool used to discover the Heartbleed vulnerability, is used to test all external interfaces and communication protocols of the product.

Learn more about the UL CAP program here.

Back in my Codenomicon days security researcher Billy Rios and I began looking at software running on medical devices using our Appcheck product (now known as Synopsys Protecode SC). We were hoping to find a few software vulnerabilities to determine how effective our product was at finding such bugs. Once we began investigating we were quite taken aback by how many vulnerabilities were present on the medical devices. We typically saw bugs numbering in the two digit range on the low side, and into the thousands on the high side. Wow!

It occurred to me that the processes in place to address medical device security issues, both from the industry standpoint and the regulatory standpoint, were perhaps in need of some serious soul searching in order to address this runaway issue. One product we tested had over 1600 vulnerabilities and when graphed over time we determined that nearly one new vulnerability was affecting it per day.

I sent the CareFusion Pyxis SupplyStation results with over 1400 vulnerabilities to the FDA as a reminder that a bit more urgency was perhaps in order. They sent the report to DHS ICS-CERT, and this began a process between me, ICS-CERT, and CareFusion (now owned by BD). The person I worked with directly at BD was Rob Suarez, who I had worked with (briefly) while he was with another medical device vendor. What struck me about working with Rob and his team at BD is that they did not deny any of the vulnerabilities existed, and also offered up all affected systems (6 total), voluntarily for use in the advisory.

Here is the offical advisory from ICS-CERT.

In summary, there are six affected CareFusion products, with a total of 1418 vulnerabilities present in seven different third-party vendor software packages. Here is the breakdown:

VULNERABLE THIRD-PARTY SOFTWARE VERSIONS

Version 8.1.3 of the Pyxis SupplyStation system, last updated around April 2010, was tested and determined to contain 1,418 vulnerabilities that are present in 7 different third-party vendor software packages, spread across 86 different files. The breakdown of the 1,418 vulnerabilities by CVSS score is as follows:
• 715 vulnerabilities were identified as having a CVSS base score of 7.0-10.0,
• 606 vulnerabilities were identified as having a CVSS base score of 4.0-6.9, and
• 97 vulnerabilities were identified as having a CVSS base score of 0-3.9.

Third-party software components for these legacy versions of the Pyxis SupplyStation are:
• BMC Appsight 5.7,
• SAP Crystal Reports 8.5,
• Flexera Software Installshield,
• Microsoft Windows XP,
• Sybase SQL Anywhere 9,
• Symantec Antivirus 9, and
• Symantec pcAnywhere 10.5.

VULNERABILITY DETAILS

EXPLOITABILITY
These vulnerabilities could be exploited remotely.

EXISTENCE OF EXPLOIT
Exploits that target these vulnerabilities are publicly available.

DIFFICULTY
An attacker with low skill would be able to exploit many of these vulnerabilities.

It is important to note here that the issues are in the third-party packages, which we have been preaching about for the last several years. Up to 90% of the software used in development today is third-party.

In closing, I want to stress that BD was very cooperative, and wishes to continue collaborating with us and other security research organizations.

Kudos to Rob Suarez and the BD team, and to Billy Rios for his great work with Synopsys!

An often overlooked aspect of software development is secure software design. With rapidly changing technologies, tight release schedules, and sloppy architecting to begin with, finding a securely designed application is too rare of an occurrence. Additionally, the application security community has not done a great job at providing meaningful guidance around secure software design. Fortunately, the IEEE has recently established a Center for Secure Design which has been sponsoring efforts to address this very issue. Since secure software design is such a key aspect to any meaningful secure software development program, it is worth highlighting some of their recent work.

In 2015, the IEEE Center for Secure Design released a document titled Avoiding the Top 10 Software Security Design Flaws which highlights several of the common issues that can and should be addressed while designing an application. Some of the Principals discussed in this document include Authorize After you Authenticate, Use Cryptography Correctly, and Always Consider the Users. Overall, this document a great resource for software designers and security engineers to reference while delving into an applications architecture.

To compliment Top 10 flaws document, the Center for Secure Design desired to publish more hands-on guidance detailing how to apply the principles for a realistic application. After careful consideration, we decided to publish a detailed analysis of a fictitious wearable tracking device dubbed WearFit. The system included realistic components such as a wireless tracking device, a mobile application for viewing health data and communicating with the tracking device and a centeralized server, etc. The end result is a new publication published in February 2016 titled WearFit: Security Design Analysis of a Wearable Fitness Tracker. Each of the 10 flaws discussed in the Top 10 Flaws document make in an appearance at one point or another in the design of the WearFit system. As such, it makes for an excellent case study showing how these flaws might appear and how they can be avoided.

To give an example of the type of guidance provided in the WearFit analysis, consider the section Earn or Give, but Never Assume, Trust. This section highlights several situations where trust relationships exist between different components of the WearFit system. One interesting scenario is how a user’s handheld tracking device communicates back to the centralized servers. The tracking device can pass sensitive user data through either a user’s mobile device or any other mobile device with the WearFit app installed. In both cases, the mobile device is trusted to pass the data on to the server but care must be taken to ensure that your mobile device cannot inappropriately access other users’ data (and vice versa). However, only my own tracking device is able to establish a full trust relationship with my mobile app through a device pairing process.

Both of these documents have been thoroughly researched and carefully designed by leading application security researchers, engineers, and architects. Designing applications securely will always be a challenge but having guidance like this is a good first step to help you do the right thing. Please take some time to review these documents yourself; you’re bound to find some helpful insights and suggestions.

This year’s Black Hat Asia will be held March 29-April1 at the Marina Bay Sands hotel in Singpapore. The event will include two days of training followed by two days of briefings. In the Business Hall, Synopsys will be at booth B07.

The keynote will be given by respected researcher Dino Dai Zovi. He’ll be talking about ways to devalue attacks on the Internet of Things. “This strategy is already in use in many forms around us and we will point out where it is being employed successfully,” he notes in the abstract. “Does it work? We will examine the phases of an intrusion common to both financially-motivated and state-sponsored attackers in order to show how defenses based on lowering the value versus raising the cost affect both the attacker and defender. Finally, we will explore what this strategy means for the security threats against the next billion devices.”

Briefing talks will focus on hacking firmware, drones, and mobile devices.

SAE is the standards development organization for the USA, with many of their standards being cited in both US and global regulations, particularly related to safety. For the last several years both automotive OEMs and Tier 1 suppliers, as well as many additional stakeholders in the automotive supply chain have teamed with industry experts in security to develop requirements for automotive cybersecurity. Recently this work culminated in the ratification of the SAE J3061 standard titled the Cybersecurity Guidebook for Cyber-Physical Vehicle Systems, issued by the Vehicle Electric System Security Committee. This was the result of extensive collaboration, and the work towards accelerating the ratification of this document was undoubtedly driven by the mandated recall of 1.4 million vehicles by Fiat Chrysler Automobiles do to the very public hacking incident of a Jeep Grand Cherokee exposed by security researchers Dr. Charlie Miller and Chris Valasek in the summer of 2015.

Soon after this incident occurred Synopsys was asked by members of the automotive industry to provide a draft procurement language document that they could drive through the supply chain to provide the industry with a means of ascertaining a level of cyber assurance that the industry could use to sign off on security. We quickly produced this document and freely distributed to the industry, and it was very well received. Additionally, members of the automotive industry began to coalesce around the notion of developing cybersecurity testing requirements that the industry could use to provide a consistent methodology for determining the cybersecurity assurance level for all systems and devices throughout the entire automotive supply chain. In March of 2016 (this month) the task force was formed under the J3061 working group, and Mike Ahmadi, Global Director of Critical Systems Security for the Synopsys Software Integrity Group (and author of the aforementioned procurement language) was offered the chairmanship of the working group, which he graciously accepted.

Prior to the creation of the SAE working group interest throughout the automotive industry for creating cybersecurity testing standards was so high that Mike Ahmadi led a grass roots working group known as the Featherstone working group (so named because the first meeting took place on Featherstone road at Fiat Chrysler Automobiles in Michigan), which was well attended, and formed the basis of the work that has been carried forward to the SAE task force.

Now the real work begins, but Synopsys remains confident that progress will be made rapidly, due to the precipitous interest, and overwhelming support from the automotive industry, and SAE. Stay tuned as we continue on this quest to create a cybersecurity sign off process.