Tag Archive for: cybersecurity

Jama Software® Receives SOC 2 Type 2 Attestation

In this blog, we recap our press release on Jama Software® becoming the ONLY requirements management vendor that is SOC 2 Type 2 compliant on the application layer and data center offerings.


Jama Software® Receives SOC 2 Type 2 Attestation

Jama Software is the only vendor in the requirements management and traceability space that is SOC 2 Type 2 compliant both on the application layer and the data center offerings.

Jama Software®, the leading requirements management and traceability solution provider, has announced that it has completed its SOC 2 Type 2 audit, performed by KirkpatrickPrice. This attestation provides evidence that Jama Software has a strong commitment to security and to delivering high-quality services to its clients by demonstrating that they have the necessary internal controls and processes in place.

“The SOC 2 audit is based on the Trust Services Criteria. Jama Software delivers trust-based services to their clients, and by communicating the results of this audit, their clients can be assured of their reliance on Jama Software’s controls.”
Joseph Kirkpatrick, President, KirkpatrickPrice

A SOC 2 audit provides an independent, third-party validation that a service organization’s information security practices meet industry standards stipulated by the American Institute of Certified Public Accountants (AICPA). During the audit, a service organization’s non-financial reporting controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system are tested. The SOC 2 report delivered by KirkpatrickPrice verifies the suitability of the design and operating effectiveness of Jama Software’s controls to meet the standards for these criteria

“We take great pride in being the first and only multi-tenant, pure-SaaS offering in our space. And now, with SOC 2 compliance, Jama Connect customers have additional validation and confidence that they are getting unparalleled best-in-class security, business continuity, and can further mitigate risks and scale with compliance.”
Marc Osofsky, Chief Executive Officer, Jama Software

Click below if you wish to learn more and start using Jama Connect:


About KirkpatrickPrice

KirkpatrickPrice is a licensed CPA firm, PCI QSA, and a HITRUST CSF Assessor, registered with the PCAOB, providing assurance services to over a thousand clients in North America, South America, Asia, Europe, and Australia. The firm has more than a decade of experience in information security by performing assessments, audits, and tests that strengthen information security practices and internal controls. KirkpatrickPrice most commonly performs assessments on SOC 1, SOC 2, PCI DSS, HIPAA, HITRUST CSF, GDPR, ISO 27001, FISMA, and FERPA frameworks, as well as advanced-level penetration testing. For more information, visit www.kirkpatrickprice.com.

About Jama Software

Jama Software is focused on maximizing innovation success. Numerous firsts for humanity in fields such as fuel cells, electrification, space, autonomous vehicles, surgical robotics, and more all rely on Jama Connect® to minimize the risk of product failure, delays, cost overruns, compliance gaps, defects, and rework. Jama Connect uniquely creates Live Traceability™ through siloed development, test, and risk activities to provide end-to-end compliance, risk mitigation, and process improvement. Our rapidly growing customer base of more than 12.5 million users across 30 countries spans the automotive, medical device, life sciences, semiconductor, aerospace & defense, industrial manufacturing, financial services, and insurance industries. Visit us at jamasoftware.com.

Read the entire press release here! Jama Software® Receives SOC 2 Type 2 Attestation


FDA Updates to the Medical Device Cybersecurity Guidance

FDA Updates to the Medical Device Cybersecurity Guidance

With an increase in connected medical devices, cybersecurity has become a hot topic for regulatory agencies. In the last few years, cybersecurity incidents have impacted medical devices and hospital networks disrupting the delivery of medical care and potentially putting patients at risk. Cybersecurity is the process of preventing unauthorized access, modification, misuse, denial of use, or simply the unauthorized use of information that is stored, accessed, or transferred from a product to an external recipient.

The focus on cybersecurity has led to several cybersecurity related guidance documents being published in the last few years. These guidance documents can be used by manufacturers to ensure that they are addressing cybersecurity in a way that meets the expectation of regulatory agencies. Some of the most important guidance documents available include:

The FDA originally released the Content of Premarket Submissions for Management of Cybersecurity in Medical Devices guidance in 2014, which was a total of nine pages long and covered the elements of a cybersecurity process and the core functions of a cybersecurity framework (Identify, Protect, Detect, Respond, and Recover). The April 2022 update to the guidance is forty-nine pages and addresses cybersecurity as part of both the Quality Management System (QMS) and the Total Product Lifecycle (TPLC). According to the FDA, the changes in the guidance are intended to further emphasize the importance of ensuring that devices are designed securely and to be capable of mitigating emerging cybersecurity risks throughout the TPLC, as well as more clearly outline the FDA’s recommendations for premarket submission information to address cybersecurity concerns.


RELATED: 5 FBI Recommendations for Medical Device Cybersecurity


Keeping in mind that the changes to the guidance were to ensure that cybersecurity is addressed as part of the TPLC and the QMS, the following specific requirements have been added to the cybersecurity guidance:

  • The guidance attempts to ensure that manufacturers are doing everything needed to design devices that are secured. The FDA now requires manufacturers to implement development processes that account for and address cybersecurity risks as part of design controls (21 CFR 820.30). This includes identification of security risks, the design requirements for how the risks will be controlled, and evidence that the controls are effective.
  • The FDA recommends the implementation and adoption of a Secure Product Development Framework (SPDF) to address cybersecurity throughout the TPLC. An SPDF is a set of processes that reduce the number and severity of vulnerabilities in products throughout the device lifecycle; using an SPDF is one approach to help ensure that QSR requirements are met.
  • The guidance includes requirements for labeling to provide information pertaining to the device’s cybersecurity controls, potential risks, and other relevant information
  • The guidance requires a Security Risk Management Process (at an organizational level) to identify, assess and control security risks. The process for performing security risk management should be a distinct process from performing safety risk management as described in ISO 14971:2019. FDA recommends that manufacturers establish a security risk management process that encompasses design controls (21 CFR 820.30), validation of production processes (21 CFR 820.70), and corrective and preventive actions (21 CFR 820.100) to ensure both safety and security risks are adequately addressed. The Safety Risk Management process and the Security Risk Management Process, although separate, must be integrated, so that Security risks that can result in patient harm, once identified, can be evaluated and assessed for risk acceptability using the Safety Risk Management process. When a security risk or control measure could have a possible impact on patient safety or medical device effectiveness, then it should be included in the product risk assessment. Likewise, any risk control that could have an impact on security should be included in the security risk assessment.
  • FDA recommends that threat modeling be performed throughout the design process to inform and support the risk analysis activities.
  • The guidance requires that Cybersecurity risks posed by third party software components must be addressed and evidence be included in the Design History File.
  • The guidance recommends the use of a Software Bill of Materials (SBOM) and specifies the information required to be contained in the SBOM, or as part of the documentation.
  • The guidance specifies requirements for a Security Risk Management Plan and a Security Risk Management Report.
  • The guidance requires vulnerability testing and penetration testing, along with verification of effectiveness of security controls.
  • The guidance specifies a requirement for a Vulnerability Communication Plan, since cybersecurity risks evolve as technology evolves throughout a device’s TPLC, FDA recommends that manufacturers establish a plan for how they will identify and communicate vulnerabilities that are identified after releasing the device. The Vulnerability Communication Plan should also address periodic security testing.

RELATED: MDIC, HSCC Team Up to Establish Medical Device Security Benchmarks


In summary, the new FDA cybersecurity guidance raises the bar on how FDA expects industry to address cybersecurity throughout the TPLC and imposes requirements for additional deliverables, testing, and labeling.



 

SITA Unveils eVISA and ETA to Transform Borders

Jama Software is always on the lookout for news on our customers that would benefit and inform our industry partners. As such, we’ve curated a series of customer spotlight articles that we found insightful. In this blog post, we share content, sourced from Times Aerospace, about one of our customers, SITA titled “SITA unveils eVISA and ETA to transform borders” – which was originally published on July 28, 2022.


SITA unveils eVISA and ETA to transform borders

SITA has launched SITA eVisa and SITA Electronic Travel Authorisation to meet the growing demand from governments for digital visa systems to stimulate national economies after COVID-19.


RELATED: Customer Story: How SITA Manages Complex Product Development with Globally Distributed Teams


Governments globally are shifting to modern travel authorization solutions, like electronic visas and Electronic Travel Authorisations (ETAs). According to the World Travel & Tourism Council (WTTC), traditional visas – applications made via a consulate or embassy – decreased from 77% in 2008 to 53% in 2018. There is a growing demand for digital travel solutions.

The advantages of digital authorization solutions include improved security, reduced administrative burden, easier travel, and increased visitor flows, promoting spending that benefits local economies and creates employment. For example, one government’s introduction of an eVisa scheme covering 40 plus countries in 2014-2015 led to a 21% increase in international visitor arrivals and the creation of 800,000 jobs accounted for around 20% of the growth seen in the country’s travel and tourism over the period.

The mobile capability of SITA’s new eVisa and ETA capability allows travelers to make applications and provide their biometric information using their personal devices before they travel.

SITA’s eVisa and ETA solutions provide visas containing ICAO’s Visible Digital Seal (VDS), an encrypted bar code that enables visas and ETAs, paper or electronic, to be digitally verified for authenticity, offering enhanced security and fraud prevention.


RELATED: 15 Digital Twin Applications and Use Cases by Industry in 2022


Jeremy Springall, Head of SITA AT BORDERS, said: “Adopting eVisa and ETA supports national prosperity. We’ve productized our proven and robust travel authorization systems to benefit more nations around the world as they shift to digitalize and future-proof their borders. The solutions help countries to cope with growing passenger volumes, improve security and efficiency, and deliver a more seamless travel experience that travelers demand, removing the complexities of applying for traditional visas”.

Springall added: “The adaptability of these two solutions means that they are fully interoperable with existing border control and airline systems. And, they comply with international standards and best practices.”

RELATED


How EN 50128 Establishes Functional Safety Standards for Railway Software

How EN 50128 Establishes Functional Safety Standards for Railway Software

In increasingly complex, rapidly evolving, and highly regulated industries, product development teams must build safety-critical products, while streamlining risk management and keeping accuracy and security at the forefront. This blog post will define functional safety and EN 50128 and explain why compliance with safety standards is critical to railway software and industrial manufacturing teams.

What is Functional Safety?

As part of the overall safety of a system or piece of equipment, functional safety is a key component that builds upon automatic protection. The best way to reduce risks in industrial manufacturing is to ensure automated protection systems have predictable responses to malfunctions or failures.

The concept of functional safety applies to everyday life and every industry you can think of. The International Electrotechnical Commission (IEC) provides this example of transportation functional safety:

“When you board a train, the subway or a cable car, functional safety ensures that the doors close before the vehicle departs and that they don’t open while it is in movement. They also ensure that the railway signaling system helps avoid that an oncoming train crosses your train’s path.”

When systems fail to operate, significant disasters can occur. Safety standards, such as EN 50128, are designed to reduce risk tolerance around these events.

What is EN 50128?

EN 50128 is a certification standard issued by CENELEC (the European Committee for Electrotechnical Standardization). The international version of this standard is IEC 62279. This standard specifies the requirements for railway applications, including communication, signaling, and processing systems for railway control and protection systems software.


RELATED: IEC 61508 Overview: The Complete Guide for Functional Safety in Industrial Manufacturing


According to Engineering360, the European standard “specifies the process and technical requirements for the development of software for programmable electronic systems for use in railway control and protection applications.” It aims toward any practical use where there are safety implications. This European Standard applies exclusively to software, the interaction between software and its system, and all safety-related software used in railway control and protection systems, including:

  • Application programming
  • Operating systems
  • Support tools
  • Firmware

Why compliance with safety standards such as EN 50128 is critical to railway software and industrial manufacturing teams

Eliminating all chances of risk may not always be possible. However, manufacturers must continuously seek strategies to mitigate potential safety issues, which is why industry experts in industrial manufacturing have created standards, such as EN 50128, and IEC 62279, to reduce risk and support the development of safety-sensitive products.

According to TUV SUD, “functional safety ensures that safety risks due to hazards caused by the mal-functional behavior of systems are reduced to an acceptable level. These safety risks are increasing in the rail industry as rail technology is becoming more and more complex, with both hardware and software interacting in different ways and components that are sourced from multiple markets.”


RELATED: The Top Six Things You Should Know About TÜV SÜD


How Jama Connect® Can Help Organizations Achieve EN 50128 Compliance

Compliance is an essential goal for organizations in regulated industries, but it is not the only factor when delivering safe and reliable products to market. Organizations need defined processes for development and production and detailed end-to-end traceability to achieve compliance, from high-level user needs to validation and verification.

Jama Connect® is TÜV SÜD certified for developing safety-related products. Jama Software® is the first vendor that is both SaaS and Agile to receive the certification. In 2019, Jama Software completed additional certification as a software tool for railway applications according to EN 50128.

Focus and rigor in the product development lifecycle drives compliance as an outcome. While the ultimate responsibility of functional safety remains with the customer, Jama Connect eases the path to compliance so companies can focus on building products right.

Ensuring Compliance & Managing Risk with Jama Connect

Jama Connect is engineered to ensure quality with frameworks aligned to key industry standards which streamline design, development, testing, and risk management while maintaining compliance. Teams can quickly see the full historical context around a requirement when they contribute to a project — reducing the probability of errors as well as the time and overhead spent on risk analysis.

Interested in learning more? Watch our webinar, Lessons Learned for Reducing Risk in Product Development



[Webinar Recap] Implementing Requirements Management for ISO 21434

In this blog, we recap the “Implementing Requirements Management for ISO 21434” webinar.


As the automotive industry becomes more complex and more connected, cybersecurity is emerging as a major concern, and therefore priority, for development teams.

According to Juniper Research, there are 206 million cars on the road with embedded connectivity and by 2025, the number of vehicles leveraging 5G embedded connectivity will surpass 30 million –– over eight million of those in the United States alone.

One standard in particular has been developed to address cybersecurity risks in the design and development of car electronics – ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”

In this session we will discuss:

  • Overview of managing requirements in ISO 21434
  • Similarities between requirements for functional safety and cybersecurity
  • Updating an example requirements management data model for cybersecurity requirements
  • Proposal for implementing a TARA in a requirements management database

Below is an abbreviated transcript and a recording of our webinar.


Implementing Requirements Management for ISO 21434

Adrian Rolufs: Welcome to this webinar on Implementing Requirements Management for ISO 21434. My name is Adrian Rolufs, and today I’ll be taking you through the process we went through at Jama Software to update our data models for supporting 21434. I am the Director of Solutions at Jama Software, focused on our automotive and semiconductor business, and my experience is primarily focused on working with customers who are implementing requirements management and traceability solutions in the automotive industry. Today, we’ll go through an overview of what the impact on requirements management is from 21434. We’ll discuss the similarities between the requirements for functional safety and cybersecurity as it applies to requirements management. We’ll go through an example of how we updated the requirements management data model to support the cybersecurity requirements. And then we also have a proposal for how to implement a TARA in their requirements management database. We’ll go through reasons why you might want to consider such a solution. So, let’s dive into it.

First of all, let’s spend a little bit of time explaining what Jama Software is. Jama Software is a company that produces a requirements management solution. We focus on providing a complete tool for implementing a V model, all the way from high-level needs analysis into requirements and system design, through to integration and verification and validation. Our customers use Jama for managing requirements, building traceability to verification and validation, and reviewing all of that in a live online database to make sure that their documentation is of high quality, as well as making it as easy as possible for engineers to do that. And as you can see, there are a lot of companies across industries, especially in automotive, that have adopted our solution as their primary requirements management solution.

So let’s talk a little bit about the impact that 21434 has to requirements management. As you’re maybe familiar, there’s a number of clauses in 21434 focused on the cybersecurity engineering best practices for development of road vehicles. It focuses on development of electronic and software systems and specifically goes through and defines best practices for the processes for identifying cybersecurity risks, identifying ways to mitigate those risks, as well as development of the products that are going to implement features to mitigate those cybersecurity risks. And it supports the implementation of a cybersecurity management system which is required for many automotive manufacturers these days.


Related: What is the Urgency Behind Automotive Cybersecurity?


Adrian Rolufs: So within the framework of ISO 21434 there are specific areas that have the biggest impact to your requirements management process. The first one is within the cybersecurity activities and assessments. There are planning documents, there’s a cybersecurity case that has to be developed, and there are work products that have to be managed to be compliant with ISO 21434. And a lot of those have an impact to the work that would typically be done in a requirements management solution. So we’ll be looking at taking those requirements into account in how you would use a requirements management solution. The really core piece of it is the concept and product development phases of ISO 21434. Those directly result in new requirements that need to be managed, designed, that needs to be implemented to meet those requirements and verification and validation activities. And these are the core activities that are typically managed in a requirements management solution, like Jama Software’s Jama Connect.

This is also a really important area to avoid creating silos in an organization. It’s very easy to create different organizational structures for managing cyber security from traditional requirements management processes. And it’s our belief at Jama Software that all requirements should be managed in a comprehensive and consistent way so that development teams can easily see what all the requirements they need to meet, and the organization can track all requirements in the same way. This leads to higher quality products, leads to more consistency, and it leads to more on time delivery. So as we’ll see today, we have developed a framework that allows you to manage these requirement design and verification and validation artifacts that are specifically required for cyber security in the same way as you would manage other requirements in verification and validation.


Related: Design Transfer: Best Practices for Translating Your Device Design into Manufacturing Specifications 


Adrian Rolufs: So another standard that a lot of organizations are following when they’re thinking about cyber security is ISO 26262. So this is the standard for functional safety and road vehicles, and it’s very common that a product or a system that needs to adhere to the cybersecurity standards also will have functional safety considerations as well. And so it’s very common to have a process that needs to accommodate both of these standards. Fortunately, there are quite a few similarities between them so it’s quite easy to develop a process that can allow you to build systems that meet both standards. Both of the standards start from the identification of an item, which is also commonly the system that you are analyzing, and help you identify the risks to functional safety or to cybersecurity, and then derive new requirements on your system in order to be able to mitigate against those risks.

They both define a V model that allows you to organize requirements and validation and verification according to system engineering best practices. And they both cover the development of a conceptual system, the full system, and then the hardware and software within those systems. And specifically, they both focus on the electronics and the software that runs on those electronics as opposed to mechanical systems, which typically don’t really have a functional safety or a cybersecurity consideration.

So in order to bring those aspects of those standards into a requirements management data model, we need to take a look at what those standards require and how is that similar or different than how you would typically implement requirements management without taking those standards into consideration. So let’s take a look at the key aspects that feed into product development. So for many organizations, they’re already considering functional safety analysis as an input to their product development. So developing a new product starts with market analysis, understanding what the needs in the market are, understanding what types of products you could build to meet those needs. And that’s the key driver for the business justification for developing the products in the first place, and building a product that’s going to meet the needs of the market. So, that’s always the first and foremost consideration.

To watch the full webinar, visit: Implementing Requirements Management for ISO 21434

RELATED


MDIC, HSCC Team Up to Establish Medical Device Security Benchmarks

Jama Software is always on the lookout for news and content to benefit and inform our industry partners. As such, we’ve curated a series of articles that we found insightful. In this blog post, we share content sourced from HealthITSecurityMDIC, HSCC Team Up to Establish Medical Device Security Benchmarks  – which was originally published on June 2, 2022, by Jill McKeon.


MDIC, HSCC Team Up to Establish Medical Device Security Benchmarks

Experts from MDIC, HSCC, and BD discuss a new self-assessment tool that aims to establish medical device security benchmarks.

The Medical Device Innovation Consortium (MDIC) and the Public Health Sector Coordinating Council (HSCC), in partnership with Booz Allen Hamilton, created a new survey with the goal of establishing medical device security benchmarks.

Medical device security continues to be a pain point for healthcare organizations, regulators, and manufacturers. The sheer number of devices on an organization’s network at any given time, along with the prevalence of legacy devices and a lack of industry-wide standards, have posed significant security challenges.

Over the years, there has been a lot of finger-pointing and confusion surrounding roles and responsibilities for medical device security.

Dig Deeper:


Related: Notable Changes in the New FDA Draft Guidance – Content of Premarket Submissions for Device Software Functions


“There was no mutual understanding about shared responsibility between device manufacturers, hospital systems, and healthcare providers,” Greg Garcia, executive director for cybersecurity at HSCC, explained in an interview with HealthITSecurity.

“We quickly recognized that as a sector, we needed to be doing something about this rather than just staying in our corners.”

In an effort to address these concerns and promote shared responsibility for medical device security across the industry, the HSCC Joint Cybersecurity Working Group (JCWG) issued the Joint Security Plan (JSP) in 2019. The JSP is essentially a product lifecycle reference guide to developing, deploying, and supporting secure medical devices and health IT products and solutions.

“The JSP is expected to evolve over time and the HSCC intends to establish a governance model to ensure the baseline strategy is updated based on execution of existing plans or new needs identified by members of the stakeholder community,” the 2019 document stated.

The new 44-question survey, based on the JSP, intends to deliver on that statement. The survey serves as a self-assessment tool for medical device manufacturers, helping them identify their own medical device security maturity in areas like risk management, design control, structure, and governance. Use of the JSP is not required for survey participation, and companies using other maturity models can also gain valuable insights from the survey results.


Related: Understanding Integrated Risk Management for Medical Device


Along with measuring the successes and shortcomings of the JSP, the survey will provide much-needed benchmark data on medical device security maturity. MDIC and HSCC are seeking one survey response per company or organization, and all responses are confidential.

“When manufacturers contribute to the survey, they will get a score that will help them to assess their posture in the sector,” Jithesh Veetil, program director at MDIC, explained in an interview with HealthITSecurity.

“And the learning, in turn, will help the industry, and also help us help the Public Health Sector Coordinating Council to update the JSP framework.”

Senior-level product security officers, risk managers, and quality managers were encouraged to complete the survey based on their working knowledge of their organization’s security posture and product portfolio.

“Cybersecurity risk is also a potential patient safety risk. It’s about protecting patient safety. It’s about protecting patient privacy,” Rob Suárez, CISO at BD and chair of the MDIC cybersecurity working group, told HealthITSecurity.

“That is really the reason why we want to give medical device cybersecurity this level of attention.”

RELATED



What is the Urgency Behind Automotive Cybersecurity?

What is the Urgency Behind Automotive Cybersecurity?

From a Market Perspective:

As automobiles are growing increasingly connected, digitized, and complex, automotive cybersecurity has become top of mind. Made up of hundreds of “tiny computers” – each with its own networks and servers – a singular vehicle is open to millions of opportunities for cyber-attack.

In fact, computers control almost every system in a vehicle, from steering to brakes, to the engine itself. Electric Vehicles (EV) have even more opportunities for cyber-attacks, as a standard EV runs over 100 million lines of code.

Without proper precautions and protection, an automobile’s data can be stolen – or worse, hackers can take remote control of the car.

From a Regulatory Perspective:

UNICE WP.29 is a global forum (comprised of 58 states) for road vehicles, agricultural vehicles, and some off-road vehicles. This governing body sets mandatory homologation requirements for member-states. Original Equipment Manufacturers (OEMs) are also required to comply to put new vehicles on the road.

Adopted by UNICE, UN R155 requires developers of automotive parts or vehicles to have a Cybersecurity Management System (CSMS). Additionally, UN R156 is a regulatory requirement for a Security Update Management System (SUMS).

Implementation of ISO 21434 fulfills the requirements for a CSMS according to R155. These requirements apply to the vehicle and all components of the vehicle that access vehicle internal communication buses.

UN R155 and R156 – Who Does This Apply to and When Does it Take Effect?

Starting in January 2021, all passenger cars, vans, trucks, and buses have been required to comply with UN R155 and R156. Additionally, Japan has indicated that it plans to apply these regulations to all automobiles that are entering the market. The Republic of Korea has adopted a stepwise approach, introducing the provisions of the regulation on cybersecurity in a national guideline in the second half of 2020, and proceeding with the implementation of the regulation in a second step.

Starting in July of 2022, the European Union (EU) will mandate the regulation on cybersecurity for all new vehicle types and will become mandatory for all new vehicles produced from July 2024 (including components).

Given the widespread use of UN Regulations in the automotive sector around the world, the broad adoption of these regulations across the world is expected, among and beyond the 54 Contracting Parties to UNECE’s 1958 Agreement.


Learn more about simplifying validation: 5 Challenges in Automotive Product Development


Ease the Challenges of Validating Product Development with Jama Connect for Automotive

Jama Connect for Automotive is designed to help those in the automotive industry get ramped up quickly with a single platform, training, and documentation aligned to industry standards and regulations including ISO 26262:2018 and ASPICE, while applying a proven systems engineering approach to product development.

Key components of Jama Connect for Automotive include:

  • Frameworks aligned to key industry regulations
  • Procedure and configuration guides specific to automotive manufacturing activities
  • Document export templates aligned with the automotive industry
  • Functional Safety Kit reduces time required for platform validation
  • Consulting and training customized to your teams’ automotive product development processes

A Single Platform for Building Safety-Critical Products

Requirements Management

Manage and validate complex systems requirements while eliminating the risks and inefficiencies associated with documents-based and legacy systems.

Hazard Analysis & Risk Assessment

Meet functional safety standards and identify and mitigate hazards earlier in development, helping teams avoid frustrating and costly late-stage design changes.

Procedure and Configuration Guides

Accelerate adoption and improve functional safety compliance using procedure and configuration guides developed for the automotive industry.

Standard Frameworks

Accelerate adoption and improve compliance using frameworks aligned to key industry regulations: ISO 26262:2018 and Automotive SPICE (ASPICE) – a process maturity framework derived from ISO IEC 15504 standard.

Test Management

Align tests and requirements, run test cases, and instantly log connected defects when tests fail.

Export Templates

Support the automotive product development process with export templates developed for the automotive industry.


Learn more about simplifying validation: A Complete Guide to Automotive Safety Integrity Levels (ASIL)


Functional Safety Kit for Automotive Development Teams

ISO 26262 stipulates that automotive developers must validate their software tools to ensure that they are suitable for use in developing safety-related items.

The Functional Safety Kit for Jama Connect is designed to reduce the time required for validation by providing a complete list of Jama Software’s internal mechanisms, workflows, and usage scenarios that we have certified by the internationally recognized testing body, TÜV SÜD, for every product release.

The Functional Safety Kit comes with process documentation, critical workflows/safety manual, and a TÜV SÜD certificate and report indicating that Jama Connect is suitable for use in the development of safety-related software according to EN 50128 – IEC 61508 and ISO 26262 up to SIL 3 or ASIL D.

Download our entire Jama Connect for Automotive Guide HERE



FDA Releases New Guidance on Cybersecurity for Medical Device

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:

  1. Threat Modeling
  2. Third-Party Software Components
  3. Security Assessment of Unresolved Anomalies
  4. Security Risk Management Documentation
  5. 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.

RELATED


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.”

Medical Device Security Predictions for 2002

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.”