In this blog, we define GAMP®5, the framework for a risk-based approach, with an introduction and conclusion provided by Jakob Khazanovich, Medical Device Solutions Consultant at Jama Software®.
What is GAMP®5 and How Does Its Guidance Help Regulated Companies Using Computerized Systems?
When medical product companies decide to implement a new software tool, an important question arises regarding the level of computer system validation required to ensure the latest software complies with regulatory requirements and industry standards.
One major guidance document companies should reference to answer this question is Good Automated Manufacturing Practice (GAMP®5): A Risk-Based Approach to Compliant GxP Computerized Systems.
GAMP® is a set of guidelines for producing quality equipment using the concept of prospective validation following a life cycle model. It was specifically designed by the International Society for Pharmaceutical Engineering (ISPE) to aid suppliers and users in the pharmaceutical industry.
GAMP stresses the use of critical thinking and risk-based assessments to justify the testing approach of a software tool. Its guidelines are widely supported by regulatory agencies and are used globally by regulated companies using computerized systems for compliance and validation.
What is GAMP®5?
GAMP®5 refers to the ISPE’s guidance document, “GAMP®5: A Risk-Based Approach to Compliant GxP Computerized Systems”. This GAMP®5 guide offers a framework for a risk-based approach to computer system validation in which a system is evaluated and assigned to a predefined category based on its intended use and complexity.
Though the steps in this guidance document are not mandatory, the framework provides a comprehensive approach to computer system validation that is generally accepted within the industry.
Based on input from experienced IT, automation, and software practitioners, one of the reasons GAMP® guidance has always been successful is because it reflects the good practices for modern IT and software engineering teams.
Released in July 2022, GAMP® 5 Second Edition prioritizes patient safety and product quality over compliance and encourages the application of critical thinking. The overall GAMP® 5 framework, key concepts, and ICH Q9 aligned Quality Risk Management approach remain unchanged from the First Edition.
GAMP® 5 Second Edition supports standards set for forth by the FDA CDER (Center for Drug Evaluation and Research). Those standards call for “maximally efficient, agile, flexible manufacturing sector that reliably produces high-quality drug products without extensive regulatory oversight, where the vision requires moving beyond simply meeting minimum CGMP standards and towards robust quality management systems.”
This updated version of the guideline aims to help teams meet compliance expectations by offering best practices for IT teams, recommendations for optimal Quality Risk Management approaches, and ways to excel in software engineering, all while achieving better product quality and safety.
Conclusion
The risk-based approach to validation is a best practice seen in guidance documents and used by best-in-class medical industry organizations, many of which are Jama Connect® customers. In general, few tools require full validation but should have functionality confirmed through a subset of tests, the scope of which is determined based on the potential risk to the patient or product.
When your organization implements Jama Connect, consider consulting GAMP®5 guidance to avoid non-value-added over-validation and unnecessary constraints on your processes and systems.
https://www.jamasoftware.com/media/2022/11/2022-11-01-gamp-5-1-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-11-23 03:00:182022-11-16 15:25:13What is GAMP®5 and How Does Its Guidance Help Regulated Companies Using Computerized Systems?
In this blog, we’ll recap our whitepaper, “When Evaluating Product Development Software Tools, Not All Cloud is Equal” – To download the entire whitepaper, click HERE.
When Evaluating Product Development Software Tools, Not All Cloud is Equal
As product development has become increasingly complex to manage across siloed teams and tools, the need for organizations to cost-effectively adapt and scale is increasingly important. Now that over 60% of corporate data is stored in the cloud. cloud-based tools have become mainstream within the engineering function. But the term “cloud” is used by vendors to describe a broad range of capabilities. Before making any software selection, it is important to understand what each vendor means when they say “cloud” and how to compare them.
The Different Types of Cloud Deployment Models: A Quick Primer
There are three types of cloud deployments: public, private, and hybrid.
Public Cloud: A public cloud infrastructure is managed by a cloud provider, and many companies use the same cloud provider. Public cloud offerings are often multi-tenant, meaning your application(s) is hosted alongside those of other companies; however, data is kept separate and secure. Some applications you might already use that leverage a multi-tenant cloud include Microsoft Outlook and Microsoft 365. Amazon Web Services (AWS) is the market share leader of public cloud providers.
Private Cloud (Outsourced Hosted): A private cloud is outsourced hosting of the application to a 3rd party. The outsource provider hosts and manages the application without the advantages of cloud architecture for scalability, high availability, security, and cost effectiveness. This approach is typically the most expensive and requires the most thorough security assessment. Often, software vendors who do not have the expertise to provide cloud hosting will outsource the hosting to their partners.
Hybrid Cloud: A hybrid cloud is a computing environment using private and public clouds and allowing applications and data to be shared between them.
Non-cloud deployment model:
On Premises (Self-hosted): A company chooses to host and manage the application themselves in their own environment. This approach is more expensive and requires the most internal resources.
Single Tenant vs. Multi-tenant Clouds: What’s the Difference?
94% of enterprises use cloud applications and the majority of their data is already in the cloud1. Here are a few important differences when comparing single-tenant with multi-tenant clouds.
Single-tenant cloud
With a single-tenant cloud you have a single instance of the software application meant to be used by your business. A single-tenant cloud is like running the application on your IT department’s hardware on-premise, but since it operates in the cloud, you’re using the provider’s infrastructure.
The drawbacks of a single-tenant cloud
Vendors that are unable to offer a multi-tenant cloud often try to scare companies away from multi-tenancy by saying it is not as secure. Of course, the entire modern economy is running on multi-tenant cloud systems from email, collaboration, task management, CRM, banking, and financial transaction systems. The need to physically separate data for security has long been solved by logically separating data and sharing databases. A multi-tenant cloud is actually more secure than a single tenant cloud against any external intrusion since it has two layers of security within the cloud environment instead of just one. Additionally, there are significant costs and risks by refusing the benefits of multi-tenancy:
Setup is complicated. A single-tenant cloud sets up a deployment stack for every customer. The provider’s burden is multiplied by every customer, making operations inefficient and error-prone since each tenant must be handled individually. The multiplicative effect increases the risks of mistakes, configuration drift, and maintenance burden.
The cost is high. Operating a single-tenant cloud is more expensive than the multi-tenant alternative since it requires a dedicated deployment stack that must be 100% paid for by the customer even when processing time and storage are not utilized.
Resources aren’t optimized. With a single-tenant cloud, you aren’t fully utilizing your resources, often leaving computing power — and money — on the table. As a result, you lose the ability to share costs for things like system monitoring, serviceability, and deployment.
Scaling is not an option. With a single-tenant cloud, you lose the ability to scale up or down resources as you need them.
More complex backups, restoration, and disaster recovery. Backing up and restoring become a stack-by-stack operation that must be managed and validated individually. In the event of a disaster, there’s no telling where your instance ends up on the priority list since they must be restored one at a time. This option also creates a single point of failure.
Here are the main benefits of a multi-tenant cloud:
Lowers your costs. A multi-tenant cloud allows the provider to leverage economies of scale. Operations, maintenance, upgrades, and scaling are done across the infrastructure base instead of one at a time. Things like backups, disaster recovery, and upgrades become simple, single operations instead of thousands of checklist-style work items. This reduces the multiplicative risk of individual operations and lowers the overall total cost of ownership (TCO).
Uses resources more efficiently. A single-tenant cloud often leaves extra resources on the table. And since you’re paying for all of it whether you use it or not, excess computing power is wasted. A multi-tenant cloud allows you to use only what you need and pay less to access it.
Gets you up and running faster. Getting up and running fast is important whether you’re a large enterprise, a smaller business, or a start-up. A multi-tenant cloud helps you quickly scale up or down to maximize resources.
Completing updates is easier. A multi-tenant cloud handles all your upgrades and updates, so you are free from disruptions and the additional costs associated with staying current.
Backups and restoration are simplified. A multi-tenant cloud backs up relevant data and resources, supporting business continuity and resilience planning.
Key Considerations When Choosing a Cloud-Based Engineering Tool Provider
What is the uptime service level agreement (SLA)?
Cloud-based software providers should be able to report their uptime at any given time and show the history of the uptime over a year.
Jama Software® publicly shows our cloud status on a minute-to-minute basis at status.jamasoftware.com
Does the provider operate in a high availability environment?
It’s not enough to have your application hosted in a major cloud (AWS, Azure, GC), the provider must design their infrastructure to be fault tolerant and adaptable to different failure scenarios.
Cloud software providers like Jama Software® provide a cloud architecture diagram that shows fault tolerance and no single point of failure.
How does the provider protect you in the event of a disaster?
While cloud services are incredibly robust, things do happen! A fully documented, tested, and validated disaster recovery plan is essential to any cloud software provider’s continuity of service.
Jama Software has a disaster recovery plan that specifies RPO and RTO objectives and it is tested at least annually in a production environment scenario
What security guarantees does the cloud software provider make?
While the underlying cloud infrastructure is incredibly secure, the software provider must take steps to secure their application. Static and dynamic scans, PEN tests, and cloud best practices (OWASP) all play a role in securing the software and your data.
At Jama Software we take security seriously and protecting our customers’ data is our highest priority. We code with Open Web Application Security Project (OWASP) best practices, host in a secure AWS cloud, perform daily static and dynamic scans, PEN test (third-party) twice a year, and are in the process of our SOC 2 Type 2 audit. Once the audit is complete, we will be the only requirements management platform on the market with a SOC 2 Type 2 certification.
https://www.jamasoftware.com/media/2022/11/2022-11-15-not-all-cloud-is-equal-1-1.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2022-11-15 03:00:592022-11-04 12:57:20When Evaluating Product Development Software Tools, Not All Cloud is Equal
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.
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.
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.
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.
https://www.jamasoftware.com/media/2022/10/2022-10-25-fda-updates-cybersecturity-guidance-1.jpg5121024Mercedes Massana/media/jama-logo-primary.svgMercedes Massana2022-10-20 03:00:252022-10-18 14:29:30FDA Updates to the Medical Device Cybersecurity Guidance
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.
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.
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
https://www.jamasoftware.com/media/2022/08/New-SITA.png5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-08-31 03:00:432022-08-31 09:13:36SITA Unveils eVISA and ETA to Transform Borders
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.
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.”
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.
https://www.jamasoftware.com/media/2022/08/2022-08-18-how-en050128-establishes-funtional-safety-standards-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-08-18 03:00:462022-08-18 08:07:54How EN 50128 Establishes Functional Safety Standards for Railway Software
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.
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.
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.
https://www.jamasoftware.com/media/2022/07/2022-07-28-implementing-requirements-management-for-iso-21434-1-1.png5121024Jama Software/media/jama-logo-primary.svgJama Software2022-07-28 03:00:362022-07-19 15:10:39[Webinar Recap] Implementing Requirements Management for ISO 21434
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 HealthITSecurity – MDIC, 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.
“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.
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
https://www.jamasoftware.com/media/2022/07/2022-07-26-mdic-hscc-team-up.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2022-07-26 03:00:532022-07-12 16:44:57MDIC, HSCC Team Up to Establish Medical Device Security Benchmarks
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.
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.
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
https://www.jamasoftware.com/media/2022/06/2022-06-28-urgency-behind-automotive-cybersecurity_1024x512.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2022-06-28 03:00:362022-06-23 16:12:04What is the Urgency Behind Automotive Cybersecurity?
In this post, we highlight and summarize parts of the new “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff.” It is important to note that this content contains non-binding guidance and therefore is not currently for implementation.
With that said, while this draft is non-binding, some organizations may adapt to this guidance proactively to address hot topics not covered in formal regulation, for example: U/X Human Factors, Software as a Medical Device (SaMD), combination products, and others.
This blog post, while quoting the FDA draft guidance directly, is not a full representation of the content. It is comprised of snippets that were particularly relevant or interesting to the author. It also does not cover any appendices.
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
The documentation recommended in this guidance is based on FDA’s experience evaluating the safety and effectiveness of devices with cybersecurity vulnerabilities. However, sponsors may use alternative approaches and provide different documentation so long as their approach and documentation satisfies premarket submission requirements in applicable statutory provisions and regulations. The increasingly interconnected nature of medical devices has demonstrated the importance of addressing cybersecurity risks associated with device connectivity in device design because of the effects on safety and effectiveness.
Cybersecurity risks that are introduced by threats directly to the medical device or to the larger medical device system can be reasonably controlled through using an SPDF.
The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. From a security context, these are also trustworthy and resilient devices. These devices can then be managed (e.g., installed, configured, updated, review of device logs) through the device design and associated labeling by the device manufacturers and/or users (e.g., patients, healthcare facilities). For health care facilities, these devices may also be managed within their own cybersecurity risk management frameworks, such as the National Institute of Standards and Technology Framework for Improving Critical Infrastructure Cybersecurity, generally referred to as the NIST Cybersecurity Framework or NIST CSF.
Security Risk Management
To fully account for cybersecurity risks in devices, the safety and security risks of each device should be assessed within the context of the larger system in which the device operates. In the context of cybersecurity, security risk management processes are critical because, given the evolving nature of cybersecurity threats and risks, no device is, or can be, completely secure. Security risk management should be part of a manufacturer’s quality system. Specifically, the QSR requires, among other things, that manufacturers’ processes address design (21 CFR 820.30), validation of the production processes (21 CFR 820.70), and corrective or preventive actions (21 CFR 820.100). These processes entail the technical, personnel, and management practices, among others, that manufacturers use to manage potential risks to their devices and ensure that their devices remain safe and effective, which includes security.
Specific security risk management documentation where FDA has recommendations regarding 354 their scope and/or content are discussed in the following subsections:
Threat Modeling
Third-Party Software Components
Security Assessment of Unresolved Anomalies
Security Risk Management Documentation
TPLC Security Risk Management
Security Architecture
Manufacturers are responsible for identifying cybersecurity risks in their devices and the systems in which they expect those devices to operate and implementing the appropriate controls to mitigate those risks. These risks may include those introduced by device reliance on hospital networks, cloud infrastructure, or “other functions” (as defined in FDA’s guidance “Multiple Function Device Products: Policy and Considerations), for example. FDA recommends that all medical devices provide and enforce the security objectives in Section IV, above, but recognizes that implementations to address the security objectives may vary.
Throughout this section, FDA outlines the recommended security controls and recommendations on how to document the resultant security architecture in premarket submissions through specific Security Architecture Views.
Cybersecurity Testing
As with other areas of product development, testing is used to demonstrate the effectiveness of control mitigations. While software development and cybersecurity are closely related disciplines, cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness.
Security testing documentation and any associated reports or assessments should be submitted in the premarket submission. FDA recommends that the following types of testing, among others, be provided in the submission:
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
https://www.jamasoftware.com/media/2022/06/2022-05-10-fda-cybersecurity-guidance.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2022-06-07 03:00:212022-06-03 12:21:14FDA Releases New Guidance on Cybersecurity for Medical Device
