cybersecurity Archives

Tag Archive for: cybersecurity

In this post, we highlight and summarize parts of the new “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff.” It is important to note that this content contains non-binding guidance and therefore is not currently for implementation.

With that said, while this draft is non-binding, some organizations may adapt to this guidance proactively to address hot topics not covered in formal regulation, for example: U/X Human Factors, Software as a Medical Device (SaMD), combination products, and others.

This blog post, while quoting the FDA draft guidance directly, is not a full representation of the content. It is comprised of snippets that were particularly relevant or interesting to the author. It also does not cover any appendices.

You can find the full draft guidance here.

Following this information, subject matter expert, Vincent Balgos, weighs in on the draft guidance. Read to the end to see his thoughts!

FDA Guidance for Cybersecurity for Medical Device

With the increasing integration of wireless, Internet- and network-connected capabilities, portable media (e.g., USB or CD), and the frequent electronic exchange of medical device related health information, the need for robust cybersecurity controls to ensure medical device safety and effectiveness has become more important.

In addition, cybersecurity threats to the healthcare sector have become more frequent and more severe, carrying increased potential for clinical impact. Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities in the U.S. and globally. Such cyberattacks and exploits may lead to patient harm as a result of clinical hazards, such as delay in diagnoses and/or treatment.

Increased connectivity and interoperability have resulted in individual devices operating as single elements of larger medical device systems. These systems can include health care facility networks, other devices, and software update servers, among other interconnected components. Consequently, without adequate cybersecurity considerations across all aspects of these systems, a cybersecurity threat can compromise the safety and/or effectiveness of a device by compromising the functionality of any asset in the system. As a result, ensuring device safety and effectiveness includes adequate device cybersecurity, as well as its security as part of the larger system. For the current edition of the FDA-recognized consensus standard(s) referenced in this document, see the FDA Recognized Consensus Standards Database.

Scope: Who Does This Apply To?

This guidance document is applicable to devices that contain software (including firmware) or programmable logic, as well as software as a medical device (SaMD). The guidance is not limited to devices that are network-enabled or contain other connected capabilities. This guidance describes recommendations regarding the cybersecurity information to be submitted for devices under the following premarket submission types:

Premarket Notification (510(k)) submissions;
De Novo requests;
Premarket Approval Applications (PMAs) and PMA supplements;
Product Development Protocols (PDPs);
Investigational Device Exemption (IDE) submissions; and
Humanitarian Device Exemption (HDE) submissions.

General Principles

This section provides general principles for device cybersecurity relevant to device manufacturers. These principles, found throughout this guidance document, are important to the improvement of device cybersecurity and, when followed, are expected to have a positive impact on patient safety.

These general principles include:

Cybersecurity is Part of Device Safety and the Quality System Regulations
Designing for Security
Transparency in Cybersecurity
Submission Documentation

RELATED: Understanding FDA Medical Device Class and Classifications, and its Impact on Requirements Management

Using an SPDF to Manage Cybersecurity Risks

The documentation recommended in this guidance is based on FDA’s experience evaluating the safety and effectiveness of devices with cybersecurity vulnerabilities. However, sponsors may use alternative approaches and provide different documentation so long as their approach and documentation satisfies premarket submission requirements in applicable statutory provisions and regulations. The increasingly interconnected nature of medical devices has demonstrated the importance of addressing cybersecurity risks associated with device connectivity in device design because of the effects on safety and effectiveness.

Cybersecurity risks that are introduced by threats directly to the medical device or to the larger medical device system can be reasonably controlled through using an SPDF.

The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. From a security context, these are also trustworthy and resilient devices. These devices can then be managed (e.g., installed, configured, updated, review of device logs) through the device design and associated labeling by the device manufacturers and/or users (e.g., patients, healthcare facilities). For health care facilities, these devices may also be managed within their own cybersecurity risk management frameworks, such as the National Institute of Standards and Technology Framework for Improving Critical Infrastructure Cybersecurity, generally referred to as the NIST Cybersecurity Framework or NIST CSF.

Security Risk Management

To fully account for cybersecurity risks in devices, the safety and security risks of each device should be assessed within the context of the larger system in which the device operates. In the context of cybersecurity, security risk management processes are critical because, given the evolving nature of cybersecurity threats and risks, no device is, or can be, completely secure. Security risk management should be part of a manufacturer’s quality system. Specifically, the QSR requires, among other things, that manufacturers’ processes address design (21 CFR 820.30), validation of the production processes (21 CFR 820.70), and corrective or preventive actions (21 CFR 820.100). These processes entail the technical, personnel, and management practices, among others, that manufacturers use to manage potential risks to their devices and ensure that their devices remain safe and effective, which includes security.

Specific security risk management documentation where FDA has recommendations regarding 354 their scope and/or content are discussed in the following subsections:

Threat Modeling
Third-Party Software Components
Security Assessment of Unresolved Anomalies
Security Risk Management Documentation
TPLC Security Risk Management

Security Architecture

Manufacturers are responsible for identifying cybersecurity risks in their devices and the systems in which they expect those devices to operate and implementing the appropriate controls to mitigate those risks. These risks may include those introduced by device reliance on hospital networks, cloud infrastructure, or “other functions” (as defined in FDA’s guidance “Multiple Function Device Products: Policy and Considerations), for example. FDA recommends that all medical devices provide and enforce the security objectives in Section IV, above, but recognizes that implementations to address the security objectives may vary.

Throughout this section, FDA outlines the recommended security controls and recommendations on how to document the resultant security architecture in premarket submissions through specific Security Architecture Views.

Cybersecurity Testing

As with other areas of product development, testing is used to demonstrate the effectiveness of control mitigations. While software development and cybersecurity are closely related disciplines, cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness.

Security testing documentation and any associated reports or assessments should be submitted in the premarket submission. FDA recommends that the following types of testing, among others, be provided in the submission:

Security requirements
Threat mitigation
Vulnerability testing
Penetration testing

RELATED: Software as a Medical Device (SaMD): Four Key Development Best Practices

Cybersecurity Transparency

In order for users to manage security risks in devices, either by an end user or within a larger risk management framework like the NIST CSF, transparency is critical to ensure safe and effective use and integration of devices and systems. This transparency can be conveyed through both labeling and the establishment of vulnerability management plans. However, different types of users (e.g., manufacturers, servicers, patients, etc.) will have different abilities to take on a mitigation role, and the need for actions to ensure continued cybersecurity should be appropriate for the type of user.

In this section, FDA provides recommendations on:

Labeling Recommendations for Devices with Cybersecurity Risks
Vulnerability Management Plans

Vincent Balgos Afterward:

In general, cybersecurity continues to be a growing and significant issue in recent years. From the Experian data breach (2017), Marriot Hotel (2018), and LinkedIn (2021), the volume of sensitive data exposed at an alarming frequency poses a significant risk. In the healthcare sector, the Scripps Health cyberattack in my hometown of San Diego, CA, some estimate that the minimal impact is expected to be >$100 million. More significantly, the potential impact of sensitive patient data out in the public domain is immeasurable.

On the medical device front, the FDA has issued recalls on a variety of devices (insulin pumps, pacemakers, etc.) citing cybersecurity risks for years. As medical device technology advances, and interoperability becomes more common, the opportunity of cybersecurity risks is ever more present.

Medical companies have (or need to soon) started considering cybersecurity as part of their standard business practices. In addition to the suggestions mentioned in the FDA draft guidance, many of us at Jama Software have seen medical company initiatives that include hiring cybersecurity experts to proactively support these efforts, incorporating a dedicated cybersecurity focus within the overall risk management procedure, and/or continued monitoring of the products and systems for potential exploits.

Since a single vulnerability can have dramatic impact, a systems approach to cybersecurity can provide valuable perspective for various levels of mitigation. In complex systems, with multiple interfaces, data streams, etc., potential vulnerabilities increase at a non-linear rate.

But how does one measure the cybersecurity level of a product’s software? An emerging metric is the Common Vulnerability Score System (CVSS) that assesses software vulnerabilities in a quantitative value. Some organizations may include this CVSS as a design requirement during the product development phase.

This approach proactively incorporates cybersecurity best practices early in the design process, which in turn demonstrates security traceability into the design, and its subsequent testing. With Jama Connect, and specifically our unique ability to create Live Traceability™ across the product development process, this cybersecurity requirement can be continually monitored (along with all other requirements) to ensure that the final product is safe, effective, and secured from potential cyberattacks.

In today’s competitive market, automobile makers are racing to define the future of transportation. And given the complexity of modern, connected automobiles, it’s imperative that vehicle safety is adequately accounted for in the product development process.

Plus, as vehicles become more complex — e.g. autonomous driving and connected systems — so too are the standards for emissions, fuel economy, functional safety, cybersecurity, and system designs.

That’s why we’ve partnered with LHP Engineering Solutions (LHP) to ensure our visionary clients comply with all relevant functional safety and cybersecurity standards — like ISO 26262 and SAE J3061 — by seamlessly integrating compliance into the product development process.

Founded in 2001 with the mission to make safer products, LHP provides a variety of engineering services and products to assist customers in speeding up their product development cycles and solving product design and testing issues.

We recently spoke with the LHP team to talk about modern challenges in complex product development, and how this new partnership between LHP and Jama Software can help. Let’s dive into what customers can gain from this partnership:

Jama Software: Can you give us a rundown of the state of the automotive industry? How is it different than 10 years ago?

LHP: The next generation of automobiles are increasingly incorporating modern electronic technologies, from on-board diagnostics to engine controllers to infotainment systems to driver assist systems. As technology advances, the trend is to partially/fully automate vehicles. While some new features are entertainment- and convenience-based, the trend for autonomous vehicles is, to a large extent, functional safety related. The end goal is to reduce the number of deaths on public roadways by providing vehicles with the ability to recognize and avoid hazards or security threats.

Safety and security are the two biggest barriers to innovation and we’re helping companies overcome those barriers. The biggest reason why we don’t see self-driving cars everywhere is because, before that happens, we must prove that they’re not going to harm people, that they’re safe, and that the software can’t be compromised and used for unintended usage.

JS: What are some of the biggest challenges facing product development teams in the automotive industry today?

LHP: Compliance to ISO 26262 and SAE J3061 involves a change in culture that is difficult for established product development teams to implement. Part of this change means looking at the product(s) being developed differently, and part is a change in infrastructure to better control the product development lifecycle and the development artifacts.

Learn more about ISO 26262 and automotive electronics development.

JS: How does leveraging the partnership between LHP and Jama Software help customers when it comes to overall functional safety as well as complying with ISO 26262?

LHP: ISO 26262 complements good systems engineering practices by requiring that hardware and software safety concerns be addressed and documented in a systematic way throughout the product development lifecycle. In the past, safety design was considered part of general requirements activity. But merely identifying and tracing requirements in the software and hardware designs is not enough. The common practice of hardware and software teams working in silos will not guarantee the level of safety coverage required by ISO 26262.

Part of LHPs offering is development of data, infrastructure consultation, and process optimization. Now, thanks to our partnership with the Jama team, we can implement proper functional safety workflows in Jama Connect, with templates to facilitate the creation of data. Additionally, Jama Software customers in the automotive industry who have questions and concerns about how to use Jama Connect to support a safety lifecycle can tap into LHPs extensive knowledge and experience in functional safety and ISO 26262.

In order to demonstrate compliance with ISO 26262, you must have the ability to manage safety requirements, including traceability. Typically, our respective customers would need to address functional safety and requirements management separately. Working together, LHP and Jama Software can address both sets of concerns in concert.

Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.

JS: What does LHP bring to the table that other requirements management platforms might not have access to?

LHP: What makes us better and unique compared to a lot of the other organizations is our wealth of knowledge. Our functional safety team actually came out of the aerospace industry with multiple decades of experience implementing safety-critical systems. The experience that they bring with them has time and time again proven to make us stand above the rest.

Just like Jama, LHP excels at custom integrations and tailoring flexible solutions for our customers. At LHP, we consult on and implement the latest automotive industry practices to ensure vehicle systems are safe, reliable, and secure. Customers come to LHP for our deep knowledge in embedded controls, integration support, and overall implementation of functional safety and cybersecurity processes.

Proving compliance with functional safety and cybersecurity standards like ISO 26262 and SAE J3061 requires a harmonious balance of processes, people, and tools. And together with LHP Engineering Solutions, Jama Software is helping automotive companies safely and confidently bring the future of transportation to market.

To learn more about how to maintain compliance with automotive functional safety standards and how to avoid common ISO 26262 mistakes, download our whitepaper, “Top 15 ISO 26262 Snafus.”

As we enter a new decade of technological advancements, Jama Software asked select thought leaders from various industries for the trends and events they foresee unfolding over the next 10 years.

In the third installment of our 2020s Predictions series, we’re featuring predictions from Chris Gates, Principal Systems Security Architect at Velentium, a professional engineering firm specializing in the design and manufacturing of therapeutic and diagnostic active medical devices.

Jama Software: What are the biggest trends you’re seeing in medical devices right now and how are they impacting product development?

Chris Gates: Regulatory bodies and Health Delivery Organizations (HDOs) are now mandating the creation and lifelong support of secure medical devices. This “Secure Lifecycle” starts with the first step in the development lifecycle and extended to the last day the medical device is marketed. This fundamental shift results in a tremendous amount of new artifacts to be managed and traced throughout the normal document tree, including security plans, requirements, test reports, post-market surveillance reports, approved supplier lists (ASL), etc., not to mention all the activities needed to create those artifacts in the first place!

JS: What are some continuing or new trends in medical device development you expect to see over the next decade?

CG: HDOs contractually mandating Medical Device Manufacturers’ (MDMs) level and nature of ongoing support for the life of the medical device in their organization, including in-field patching of software/firmware; Software Bill of Materials (SBOM); and assuming liability for all damages caused by the use or misuse of the device (such as being hacked and weaponized to attack other systems in the HDO). These are not activities or processes that have been previously supported or funded by MDMs.

JS: What sorts of process adjustments do you think development teams will need to make to accommodate these changes? Do you think they’ll need to make technology investments, process adjustments, or both?

CG: Yes, yes, and yes. This will result in large changes to organizations and how they work, plan, and budget for medical device development. For example, they’ll need “all of the above” to accommodate the ongoing post-market surveillance impacts on the utilization of third-party software packages in future devices. This is all part of the changes to the ASL. No longer can MDMs view medical device development as ‘a separate event’ with a beginning and an end. Securing medical devices is an ongoing collaborative effort with HDOs.

JS: Any regulatory changes you anticipate to medical devices over the next decade? How do you see this impacting development teams?

CG: More enforcement “teeth” being given to the FDA by Congress. Especially in the area of MDMs’ “responsible vulnerability disclosure,” which is currently optional for MDMs. However, the FDA, Congress, and HDOs are all in agreement that this activity needs to be mandatory and thus enforced. Hopefully we will see some worldwide harmonization of security standards and generated artifacts, as currently these regulatory bodies are very fractured in their approach to secure development and the generated artifacts.

JS: What do you think will remain the same in medical device development throughout the 2020s?

CG: Focus on “safety and efficacy” will remain steady, as well as a continued drive to shrink medical devices to the smallest physical package possible to enable more home healthcare scenarios. Similarly, the increased use of “telemedicine” and related connectivity solutions enabled by these home healthcare devices and smartphones.

JS: Anything else you’d like to add?

CG: Even though the transition to secure medical device development and support may be financially uncomfortable, medical device security is the responsibility of all MDMs. Remember, the patient you are protecting might be yourself or a loved one!

Significant growing and shifting regulations are already underway within the medical device industry. Learn how teams can stay ahead of the competition in our eBook, “Conquering Connectivity, Competition & Compliance.”

Despite ongoing concerns about cybersecurity, the medical device landscape has seen some amazing advances even just this year.

Putting the End User in Control

End users, consumers, and patients are finding themselves with more knowledge about — and control over — their health than ever before. And that’s thanks, in part, to recent advancements in medical tech and, wearables, in particular.

In 2018, Apple introduced the first direct-to-consumer EKG wearable “cleared” by the FDA when it rolled out the EKG and irregular heartbeat features on its Series 4 Apple Watch. The watch has been classified as a Class II medical device, and a recent Standford University study revealed it can help detect atrial fibrillation — a type of irregular heart rhythm, which is the leading cause of stroke and hospitalization in the U.S.

Combined with other medical tech advancements like Bluetooth-enabled “smart” inhalers for asthma and COPD sufferers and wearable blood pressure monitors, the medical device industry continues to trend toward giving patients better control and management over their own health. Between 2014 and 2018, consumer use of wearables jumped from 9% to 33%. There are currently almost 200 clinical trials involving medical tech wearables in progress.

The impact of such fast-moving technology is still being measured, and, among other things, it’s making some question if wearables might actually decentralize medical care by making frequent visits to the doctor’s office less necessary.

Read our eBook to learn more about risk management for Class II and Class III medical device development.

In the Field

Medical tech and medical devices continue to improve patient care in clinical settings as well.

Artificial intelligence company care.ai is working with Google to develop a “Self-Aware Room” for hospitals. This technology would monitor patient conditions and send notifications to staff to keep them apprised of patient conditions. The technology could help clinicians better manage patient safety and health by predicting things such as preventable falls, pressure ulcers, and infectious diseases that would compromise patient health.

The partnership is part of an overall trend toward edge computing in hospital settings. Though edge computing doesn’t solve all cybersecurity challenges by any means, the trend does bring computing closer to the data source — in this case, the patient — which can help to mitigate some cybersecurity challenges.

AI and augmented reality technologies are also changing operating rooms. One recent report suggests that as many as 45% of operating rooms will be integrated within the next four years. The intelligent technologies will result in less invasive surgeries and improved patient outcomes.

Microsoft and Phillips have also partnered to develop augmented reality technology for surgery. The technology would transfer live imaging and other sources of information into a 3D holographic environment that the surgeon could control.

Alex Kipman, technical fellow, AI and mixed reality at Microsoft, notes that “[m]ixed reality holds great potential in healthcare, and our collaboration with Philips shows how that potential is already beginning to be realized.”

Learn more about how Jama Connect™ helps medical device developers streamline and speed up the development process while reducing risk.

Cybersecurity Concerns

Of continuing concern for medical device manufacturers and their partners are cybersecurity threats.

The FDA recently issued a safety communication concerning the URGENT/11 security threats. These vulnerabilities were first identified in July, and they affect several operating systems used in medical tech and industrial devices.

Suzanne Schwartz, M.D., MBA, deputy director of the Office of Strategic Partnerships and Technology Innovation in the FDA’s Center for Devices and Radiological Health, noted that the FDA was not aware of any patient harm resulting from the URGENT/11 vulnerabilities. However, she noted that “the risk of patient harm if such a vulnerability were left unaddressed could be significant.”

The communication highlights the ongoing challenges of not only addressing current vulnerabilities and cybersecurity threats, but also integrating protections into medical devices currently under development. Staying one step ahead of remote attackers is always a challenge for developers in any industry, but in the medical tech realm, patient health is a very present concern. Security vulnerabilities can put patient health and safety at risk.

The FDA also recently introduced a new, voluntary program for medical device and device-led combination products. Called the Safer Technologies Program for Medical Devices, the program is designed to help expedite development, assessment, and review of certain medical devices that are not eligible for the Breakthrough Devices Program. Draft guidance for the Safer Technologies Program is available online; the commenting period ends November 18, 2019.

Learn more about recent pending updates to the FDA’s cybersecurity for premarket submissions in this blog post.

Potential for Collaboration

Though the market entry of such tech giants as Amazon and Apple can pose challenges for legacy medical device manufacturers, the Microsoft/Phillips and care.ai/Google collaborations suggest a development that could benefit all parties.

While tech giants don’t have a long history of navigating the FDA approval process, they have been grappling with cybersecurity issues for some time. Medical device manufacturers and tech giants would be wise to combine their strengths and expertise to continue to combat cybersecurity threats while bringing new medical devices to market and improving patient care.

Download our eBook, Conquering Connectivity, Competition and Compliance, to learn about the top three challenges that modern medical device makers face and how to overcome them.

This is a guest post from Velentium, which provides assistance throughout all stages of medical device development. Velentium is a partner of Jama Software, and this post originally appeared on the company’s blog.

On October 18th, 2018, the FDA released a draft guidance named “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.” Even though most of the activities and deliverables in the 2018 guidance had been the FDA’s expectations for the previous 12 to 18 months, they were not publicly documented and available to the industry until that time.

(For a complete breakdown of the 2018 Guidance, download our white paper).

The FDA has been working steadily to update the 2018 guidance, taking into account industry feedback as well as input from subject matter experts in medical device cybersecurity, including Velentium’s own Christopher Gates. The estimated final release date for these updates is the end of 2019 but bear in mind, the published draft does reflect the FDA’s current expectations for submissions!

In this post, we offer insight into anticipated changes coming in the official update. Chris’ vantage point within the industry, involvement with special interest groups, and regular contact with regulatory bodies provide us a high degree of confidence about these changes. Even so, they should not be taken as “gospel truth” until we have official FDA confirmation in the form of a published revision to the guidance.

That said, here are five (5) changes we look forward to seeing in the official update.

1. Removed: References to “Likelihood”

We view this as an extremely positive change because, as we’ve written before, “Likelihood” really has no bearing in cybersecurity. This is one place where cybersecurity management diverges sharply from quality management: when you’re mitigating patient risk due to failures, there is no malicious intent at work trying to cause any particular subsystem to fail; therefore, the likelihood that it might fail is useful to know. But as soon as malicious intent enters the picture, likelihood ceases to be relevant because there’s no way to predict whether a given vulnerability will be discovered and attacked by a malicious actor.

Even if it were possible to estimate the probability that a given attack vector will be utilized or a given system vulnerability discovered and exploited, it wouldn’t be practical information to have. Demonstrating device security to regulators is about mitigating vulnerabilities, period. It is not about arguing, based on some trumped-up metric of “likelihood,” that you don’t need to mitigate certain vulnerabilities because no-one will ever find them.

(Note that “Likelihood” of attack is not the same thing as “Difficulty” of attack, which is useful to know and part of all industry-accepted vulnerability scoring systems).

2. Replaced: the CBOM Requirement is Now an SBOM Requirement

In other words, the hardware element of the Component Bill of Materials (CBOM) will not be required, but the software element still will be. As a quick refresher, this means:

“A list of commercial, open-source, and off-the-shelf software components to enable device users (including patients, providers, and healthcare delivery organizations (HDOs)) to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the device (and the connected system), and to deploy countermeasures to maintain the device’s essential performance.”

(Source: FDA 2018 Cybersecurity Guidance)

Depending on the system, the SBOM will include all third-party software components (libraries, operating systems), and will also need to be machine-readable. Finally, the SBOM needs to be cross-referenced to a vulnerability database, such as the NVD, as a manufacturer will want to show that currently there are no known vulnerabilities. Failing to include this will almost certainly result in a pre-market submission rejection.

3. Replaced: 2018’s 1-2 Tier Structure

Not much is known yet about the pending overhaul of 2018’s security risk rating system for scaling and assigning a metric to a device, but we do know that it will not be tied to Device Risk Rating (I/II/III), or to Software Classification (A/B/C), which are based on user risk. Rather, it will be based on something else, still to-be-announced. Keep an eye on our blog — we’ll post more when we know more!

4. Revised: Guidance on Investigational Device Exemption Submissions

In the 2018 draft, a footnote on page 5 indicated that manufacturers “may… consider” applying the principles described in the Cybersecurity Guidance to Investigational Device Exemption submissions. This language will be clarified to reflect that the FDA does not consider good cybersecurity development practice “optional,” either for Investigational Device Exemption submissions or Institutional Review Board submissions.

The takeaway here is straightforward: if you plan to deploy or utilize your device at any stage of development in any way that requires first securing approval, you must demonstrate that you have taken all appropriate measures to secure your device.

At Velentium, we practice and highly recommend the secure development lifecycle. Our approach, in which security is fully integrated into the project lifecycle from Phase 0, not only ensures that your device will be compliant and that you will have generated all the artifacts needed for submission well in advance, but also that you will have identified and mitigated any threats to your business model that could stem from the project. Contact us to learn more.

5. Reformatted: the Entire Guidance.

Finally, expect a format overhaul of the PDF itself. The 2018 draft attempted to follow the layout from FDA’s initial cybersecurity guidance (originally issued in 2014), but this has proved to be a suboptimal way to organize the new content.

If your current project includes documentation that you are tracing to the structure of the guidance, you may want to hit “pause” on populating that trace matrix (unless you expect to submit those documents before the update is published). Other than that, the reformatting should have a minimal impact except to make the guidance content easier to understand.

Until fairly recently, you might not have considered vehicles to be major cybersecurity targets. But with the rise in connected and autonomous cars, hackers and other cyber criminals can break into the systems that run these vehicles and wreak havoc.

“With all of the connectivity available comes cyber risk,” says Faye Francy, executive director of the Automotive Information Sharing and Analysis Center (Auto-ISAC), an industry-driven community to share and analyze intelligence about emerging cybersecurity risks to vehicles.

Technology has a long tradition of racing ahead of oversight, and the automotive industry is still catching up to the speed of change. Updates to the ISO 26262 functional safety standard were recently made in December 2018 and touch on cybersecurity, but expect to see more emphasis on this topic in the future. That’ll be especially true as automotive connectivity and complexity escalates, and the development of autonomous vehicles (addressed by another safety standard, ISO/PAS 21448, or Safety Of The Intended Functionality (SOTIF), which has incidentally sparked its own upcoming conference in Germany) progresses.

As an additional resource, Auto-ISAC aims to enhance vehicle cybersecurity capabilities across the global automotive industry, including light- and heavy-duty vehicle original equipment manufacturers (OEMs), suppliers and the commercial vehicle sector.

“The Auto-ISAC is the go-to organization that facilitates cybersecurity resiliency for the global automotive industry,” Francy says. Automakers worldwide joined together in 2015 to form the nonprofit community to address growing vehicle cybersecurity risks.

A Shared Responsibility

The focus of Auto-ISAC is to foster collaboration for mitigating the risks of cyber attacks and to create a safe, efficient, secure and resilient global connected vehicle ecosystem,” Francy says. Members use a secure intelligence-sharing portal to anonymously share information that helps them more effectively respond to cyber threats, vulnerabilities and incidents.

The 49 members includes all major automakers across North America, Europe, and Asia, as well as suppliers to the heavy-duty trucking and commercial vehicle sector. In 2017, the Auto-ISAC established a Strategic Partnership Program to enable ongoing coordination with key stakeholders including partners, government regulatory agencies and law enforcement.

One of the key accomplishments of the Auto-ISAC is its Best Practices initiative, which focuses on developing guidelines organizations can use to advance their vehicle cybersecurity programs, Francy says. The members conceive, write and develop Best Practice guides that are in various stages of review.

The guides cover organizational and technical aspects of vehicle cybersecurity including incident response, collaboration and engagement with third parties, governance, risk management, security by design, threat detection and protection, and training and awareness.

“These guides are released to the community to help the automotive industry stakeholders mature,” Francy says. Currently there are three guides available to the public on the Auto-ISAC Web site: Incident Response, Third Party Collaboration, and Engagement and Governance.

Evolving Recommendations

The digital age has introduced connected, advanced automotive capabilities for consumers, such as driver assist, navigation and hands-free calling. But this also introduces the possibility of risk such as hacker attacks.

“We have moved from a more physical analog attack surface to a digital, networked environment,” Francy says. “This provides different opportunities for the bad actors, due to the increase in innovative technologies and the interconnectedness” of the ecosystem.

Fortunately, the industry has taken a number of actions to identify and thwart cyber threats, including implementing security features in every stage of the design and manufacturing process, collaborating with public and private research groups to share solutions, and participating in multiple cyber forums on emerging issues. There is, of course, much more work to be done.

Automotive companies can learn from the Auto-ISAC leadership as it builds and leads a community of best practices, Francy says. The organization conducts an annual tabletop exercise, quarterly workshops and monthly analyst calls with members. It also leads virtual, monthly community calls and runs an annual Vehicle Cybersecurity Summit.

Auto-ISAC partnership programs “are developed to cultivate relationships beyond our membership, with the common goal to enhance vehicle cybersecurity and develop a vibrant and robust information-sharing community,” Francy says.

Learn how a Fortune 100 semiconductor company is meeting the challenges of functional safety standards for its automotive-related technology with Jama Connect by downloading our paper.

Author Bob Violino is a freelance writer who covers a variety of technology and business topics. Follow him on Twitter.

With the rising amount of connected devices in circulation, the number of potential targets for hackers and other cyber criminals to exploit continues to rise. Among the most common targets for attack: medical devices.

A survey released in October of 148 healthcare IT and security executives, conducted by Klas Research and the College of Healthcare Information Management Executives (CHIME), showed that an astonishing 18% of provider organizations had medical devices impacted by malware or ransomware in the last 18 months.

Medical devices were defined in the report as “biomedical devices used by healthcare-delivery organizations in the pursuit of patient care.”

The report also stated that only 39% of the respondents were “very confident or confident that their current strategy protects patient safety and prevents disruptions in care.”

Although organizations are making gains in developing and maturing their overall security programs, the report says, progress has been slow. This is particularly true when it comes to securing medical devices, the study shows. Unsurprisingly, respondents cited patient safety as their top concern with unsecured medical devices.

“Unsecured and poorly secured medical devices put patients at risk of harm if those devices are hacked,” said Russell Branzell, president and CEO of CHIME, in a press release about the report. “In recent years, that risk has increased exponentially as devices in hospitals and health organizations have become more and more interconnected.”

Adam Gale, president of Klas, also weighed in on the findings: “Safeguarding medical devices requires a joint effort by provider organizations and device manufacturers. Many providers have the basic building blocks for a general security program in place and are making progress.”

A large majority of the survey respondents (96%) identified manufacturer-related factors as a root cause of medical device security issues. The majority of respondents also reported struggles related to out-of-date operating systems or the inability to patch devices, which have been found to be major security risks. The study also discovered that, on average, one third of medical device manufacturers have said their devices cannot be patched.

“Medical device security is a three-way relationship between provider organizations, the manufacturers, and the regulators,” said Dan Czech, director of market analysis-cybersecurity at Klas, in the announcement about the findings.

Provider organizations can follow industry-accepted best practices such as network segmentation, Czech said. “Manufacturers can include security in the design of all products going forward and can consistently patch currently offered medical devices,” he said. “Regulators can provide incentives and disincentives for manufacturers and organizations to secure their devices and can offer the needed guidance to direct the healthcare industry.”

The threats against medical devices have become such a concern that two U.S. federal agencies recently announced a new initiative to address vulnerabilities. In October 2018, the U.S. Food and Drug Administration and the U.S. Department of Homeland Security (DHS) announced a memorandum of agreement to implement a new framework for greater coordination and cooperation between the two agencies for addressing cybersecurity in medical devices.

“As innovation in medical devices advances and more of them are connected to hospital networks or to other devices, making sure the devices are adequately protected against intrusions is paramount to protecting patients,” said Scott Gottlieb, FDA commissioner, in the memorandum announcement.

The partnership between the two agencies will enable them to share information about the constantly evolving threats against medical devices and help organizations in the healthcare industry proactively respond when vulnerabilities are identified.

This isn’t the first time the two agencies have collaborated on medical device security. In recent years they have been focused on the coordination of vulnerability disclosures. The partnership allows device manufacturers to receive technical information from cybersecurity researchers regarding identified vulnerabilities in their products so they can respond to potential threats in a timely way.

Author Bob Violino is a freelance writer who covers a variety of technology and business topics.

Any cybersecurity expert will tell you that it’s not a matter of if you will be hacked, but when. Healthcare organizations across the country are quickly learning the truth about that axiom.

According to the most recent IBM X-Force Cyber Security Intelligence Index, healthcare tops the list of most cyber-attacked industries. And, according to Rapid7’s threat report for the first quarter of 2018, healthcare beats out industries such as finance, retail, and construction as the top targeted by hackers.

As we work through the second quarter of this year, already multiple hospitals have been affected by the ransomware SamSam. Then there’s the Orangeworm attack group that’s targeting different facets of the healthcare industry worldwide.

According to HealthITSecurity.com, hackers are increasingly targeting the healthcare industry because of its distributed IT infrastructure (which utilizes a combination of legacy systems and medical devices), constantly available systems, and the amount of sensitive data so many organizations hold.

The average cost of a cyber attack is $5 million, according to the Ponemon Institute, and can be much higher for larger organizations. Erie County Medical Center in Buffalo, NY reported the total costs associated with just one ransomware attack last year added up to more than $10 million.

Healthcare Security Risks

While healthcare IT professionals have been focusing on protecting things like servers and networks, many are learning quickly that certain types of medical devices can also provide hackers a backdoor into systems.

Additionally, despite FDA guidance, hospitals are still struggling with protecting these vulnerable targets. And points of exposure might not always be fully apparent.

As Symantec notes about the Orangeworm threat, for instance, some of the tactics being used by the perpetrators to gain access to software used to equipment like X-Ray and MRI machines are fairly dated. The reason the efforts can still be effective is because of older operating systems.

So, theoretically, even if a medical device is boasting state-of-the-art security, if it’s placed in an environment utilizing legacy software and dated operating systems, such as Windows XP, that can introduce risk.

While this may be disheartening to device manufacturers prioritizing security, they should still do what is necessary to protect their products against an attack, and assume the provider will follow safety protocols accordingly.

However, this could be considered a silo approach to cybersecurity, and the threats to medical devices really call for a strong eye on security throughout design, development and deployment.

Healthcare Information and Management Systems Society (HIMSS) is one example of an organization that wants to tear down those silos, calling for a holistic approach to cybersecurity. In its Cybersecurity Position Statement, HIMSS defines that approach:

“HIMSS calls on the healthcare community at-large to work together, and with cyber experts from other sectors, to achieve a future state in which all are prepared to defend against increasingly sophisticated and numerous cyber-attacks… Through cooperation and focused efforts, we can overcome policy, cultural and financial roadblocks, and other barriers that inhibit the development of cyber solutions that work.”

Building Cybersecurity into Product Development

Cybersecurity collaboration must be built into project frameworks that extend throughout the product’s lifecycle.

And speaking of framework, you should take some time to get familiar with the National Institute of Standards and Technology’s (NIST) Framework for Improving Critical Infrastructure Cybersecurity, or as it is thankfully referred to more commonly — “the Framework.”

The Framework is part guide and part reference manual for outside resources that can provide more detail on strengthening security. One of the advantages the Framework offers is that it gets everyone speaking the same language, which is essential if the HIMSS holistic approach takes off.

And it’s not just nice to have everyone on the same page. If you plan on doing business with the government, you’re going to have to show you follow the Framework. Healthcare industry CIOs are very familiar with it, and they are beginning to require vendors to adhere to it. You can expect more will follow.

If this all seems overwhelming and you’re not sure where to begin incorporating it into your product plans, here’s the good news. The NIST Framework was a joint effort between government and industry. One of the industry players was Intel. Soon after the first Framework was delivered, Intel launched a pilot project to test the Framework’s use. They documented the entire project and published a document serving as a use case.

Adding Value Through Education

Medical device manufacturers that take a holistic approach to cybersecurity into their projects will have an advantage to companies that do not. While many hospitals are doing a better job, physician practices still need a lot of help.

According to a survey conducted by the AMA and Accenture, 83% of 1,300 physician practices surveyed already have experienced a cyber attack. While more than half of the physicians surveyed said they were very or extremely concerned about attacks, nowhere in the survey did they directly mention medical devices.

This omission could indicate a lack of understanding on the part of the survey creators, or perhaps it shows that doctors are unaware of the fact that devices — when connected through wireless networks and aging legacy systems — could be the source of a breach.

In any case, you can bet the threats to medical devices are only going to grow more sophisticated and numerous as time passes. Those medical device companies who fail to act will gradually become larger targets for criminals. The faster security is prioritized throughout development of medical devices, and everyone in the industry gets on the same page about security, the better chance we’ll have at staving off the threats of tomorrow.

Author Traci Browne is a freelance writer focusing on technology and products.