cybersecurity Archives - Jama Software

Posts

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.

“Security is the biggest issue holding back the broader development and deployment of IoT devices,” said Haydn Povey, founder and CEO of Secure Thingz, in his keynote at Embedded Conference Scandinavia (ECS) 2018.

The Internet of Things (IoT) promises a flood of amazing new products, including autonomous cars, networked medical devices, home automation and new devices in industrial applications. But data breaches affect millions annually, and there is real fear that hacked devices could be used for surveillance, fraud or even weaponization. Unless customers trust in the security of these devices, adoption will stall.

Make Security a First-Class Citizen During Development

Too often with IoT devices, security is an afterthought; sometimes it even gets scrapped due to time and resource constraints. But organizations cannot provide reliable security after the fact. Security must be addressed from day one, by both product development and leadership.

Consider architecture: There are many chipsets available that provide a security architecture for embedded devices, but less than 4% of new devices in 2018 include embedded security. The explanation for this oversight is obvious: Development begins without security in mind, leading to an architecture that omits it. And it’s not feasible to change the underlying architecture of a product after release to account for security.

Most importantly, security is everyone’s job. It’s a management topic that should manifest on all levels in the form of policies and guidelines.

The Argument for Security in IoT Devices

Security is often seen as a cost, but if you understand it correctly, you can turn it into a value proposition or a competitive advantage that customers are willing to pay premium for. For instance:

Today’s customers are increasingly concerned with security and privacy. Companies like Apple can charge a premium because they address these concerns.
Insufficient security can lead to counterfeiting.
Good security increases brand value and decreases the risk of brand erosion.
Security is required by law, and failure to comply can result in heavy fines.

Security as an Integral Part of Product Development

Once you recognize the importance of security, it’s logical to make it an integral part of your product development process. This means, amongst other things:

Security is part of the stakeholder needs and therefore must be part of the core requirements. This also applies to regulatory requirements, such as those derived from legislation like GDPR.
Make sure your architecture fits your security requirements, since architecture is one of the most difficult (and expensive) things to change after the fact.
Ensure your security requirements are tested. You achieve this by maintaining correct end-to-end traceability from requirements to test results.
Collaborate on all levels. If you want to prevent security from being patched on an ad-hoc basis, make sure that all teams communicate properly. For instance, an engineer might be tempted to write custom code to detect a Denial of Service (DoS) attack, but this might be addressed more efficiently on the architecture level.
Implement a product line strategy and perform systematic reuse. Security extends to the complete lifecycle of products, so you must be prepared to provide security updates for years to come. Also, reuse allows teams to use previously tested elements, improve quality and accelerate development.

Embracing security today provides more than just a competitive advantage – it may be crucial for survival. While a product development platform alone is not enough to address security, it’s ideal for implementing the policies and frameworks established by management.

To better understand how Jama Software can help you ensure security throughout the product development process, visit us at Embedded World 2019.

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.

During medical device development, gaps and oversights introduce a variety of risks. Learn how medical device companies can identify and reduce risk during the development process, allowing more time for transformative innovation, with the Jama Connect Risk Management Center.

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.