Tag Archive for: Product Development & Management Page 16
Tag Archive for: Product Development & Management
Jama Connect®‘s Features in Five Series:
Your Guide to Streamlining Product Development
Learn how you can supercharge your systems development process! In our Features in Five video series, we pull back the curtains to give you a look at a few of the powerful features in Jama Connect®… in under five minutes.
Would you like to see the most up-to-date and complete upstream and downstream information for any requirement—no matter the stage of systems development or how many siloed tools and teams it spans?
Live Traceability™ in Jama Connect enables you to do just that! Now you can manage requirements with complete traceability across the end-to-end systems development process for proven reduction in cycle time and improved product quality.
This enables the engineering process to be managed through data, and its performance improved in real time; dramatically reducing the risk of product delays, cost overruns, defects, rework, and recalls; and ultimately resulting in faster time to market.
In this video, we demonstrate how Jama Connect helps teams integrate with preferred best-of-breed tools to achieve Live Traceabilty™ across the end-to-end development cycle.
Struggling with scattered requirements and disconnected systems?
Teams often struggle to build on existing work when requirements and tests are spread across documents and systems. Lacking a live trace, they must manually identify and copy related content, increasing the risk of rework and gaps. Additionally, teams tend to lack visibility across efforts, causing necessary changes to not propagate across reuse content, potentially impacting quality and disconnecting product design efforts.
Jama Connect simplifies and enhances the process of reusing requirements and verifications by allowing you to copy selected content with its containers and its traced items. Synchronization ensures visibility and enables key use cases such as parallel product definition, common content libraries, and product variance.
In this video, we explain how your team can reduce time to market and improve quality by reusing and synchronizing requirements and other content in Jama Connect.
Review Center
Are complex review processes bogging down your development process?
Reviews play a key role in successful product development. Jama Connect’s Review Center streamlines the review process, saving valuable time and making reviews across teams and various stakeholders seamless! In this video, you will learn how to initiate a review, how to invite participants to a review, how users can complete tasks, provide feedback, and finish a review. You also see how moderators can view review activity, interact with feedback, publish revisions, compare review versions, and more.
In this video, we demonstrate a powerful and easy-to-use feature in Jama Connect, the Review Center.
Jama Connect Features in Five: Integrations Series
The #1 problem product engineering organizations face is complying with traceability requirements spanning siloed teams and tools. Jama Connect helps teams solve this by offering integrations with various other applications and tools via Jama Connect Interchange™ as well as Jira, Excel, Cameo, and more.
We are excited to announce our upcoming eight-part Jama Connect Features in Five integration video series demonstrating the best-of-breed tools that plug into Jama Connect for Live Traceability!
The following is the transcript of a Q&A session from this event. Please note that the answers were given verbally and may not be exactly as recorded. Some changes have been made for clarity.
“What are some insights for product development teams to consider when keeping up with the speed of innovation?”
Chris Unger: Separate out research (from development), and spend certain time on long lead items. Typically, our programs are 6 to 18 months. And so, if there is basic research that takes more time, make sure you have a certain amount of your budget – 5, 10% – with risk retiring the initial basic piece of the work, and the handoff between research and [development] programs in where we think we can retire the remaining risks in the 12 months. And then the rest of it has to really focus on what is really core. Eating the elephant one bite at a time. Focus on what’s really innovative. But one of my general managers said, ‘You want your product development to be a wall. Big, small, small, big, small.’ Product development should be a phased approach where you work on various scoped tasks. Focus on the high-risk and most innovative stuff. Low-hanging fruit can wait. Spend the time really on the breakthrough, and then maybe every six months for the next year just do small iterations, maybe some covers, maybe some better user interface and workflow, while you’re buying time for the next major innovation to come through. So, portfolio management.
Bijan Elahi: With respect to risk management, innovation in new technologies is useful for reducing risk to medical devices. You may have seen the definition of “state of the art” in the latest edition of ISO 14971 Standard, which says that the manufacturers are required to consider the consolidated findings of technology research practice to incorporate into the medical devices to reduce risks as much as possible. However, it also says that the latest technology state of the art is not necessarily the latest technology [from all industries]. And medical devices, we are a little slower than other industries like semiconductors. So, for us, state of the art must be generally considered good practice, and then innovations that are proven and accessible to be used to reduce risk.
Chris Unger: The other comment I might make is one of the reasons you slow down is scope creep. For every function, every person is like, “I just need my one. It’s just small.” It’s the straw that breaks the camel’s back. And one of our most successful businesses, the ultrasound team, said that time to market and this time blocks delivery was a team effort. Instead of having one person beating away, that all the functions sort of gang up on each other. It’s like, “Well, I didn’t put my extra in.” We’re all committed to delivering this every year, something important every year. And so rather than having the program manager fighting for scope, it’s the team that says, “Look, I’m willing to commit to this limited scope to get something this year, you help me out.” So, make sure it’s the team’s focus on speed to market.
Vincent Balgos: In this post-pandemic event, collaboration can pose a challenge in working remote, hybrid, onsite, especially for systems engineering and risk management where we need to work across the aisle amongst different types of groups.
Vincent Balgos: “So my question to maybe Bijan first, is what are some lessons learned that you’d offer to maintain efficiency and progress, that works better than others? And we are a bunch of engineers here, definitely want to talk about technical, but are there any key soft skills that we may also want to consider as well?”
Bijan Elahi: In one of my classes, I teach that you need to cultivate humility and curiosity. So, what do I mean by that? As I said, risk management is a team sport, and humility does not mean self-deprecation, it means to recognize that the answer is not all within you, it’s within your team. And the curiosity part is that some people are just shy about sharing their thoughts. So, curiosity is to seek it. It doesn’t always just come to you. So, this is a soft skill that I can offer you, to cultivate humility and curiosity.
Chris Unger: This is a good advertisement for the February webinar I am hosting with Jama Software. I was going to plan something on requirements writing techniques, which will probably be later in the year. I’d say a couple of things, make sure that you focus on communication. So, in a crisis, a lot of people just focus on getting their work done. And the first thing that you should maintain, a lesson straight off, is making sure you talk to the team, that you get consistency and use simple forms, and keep publicizing. Example like “What are my decisions? What are the important ones?” Just keep over-communicating, it’s something simple in the survival handbook, “Guys, here’s my list of decisions, here’s my list of risks.” Keep it simple, keep it single reference.
And the other thing I do is, don’t use that to communicate, use that to archive your decisions. I get really annoyed when my team says, “I wrote defects in the tool. Of course, they’re going to respond.” Talk to people, call them up, ask them questions. Do they understand? Do they understand why it’s important to do this? Do they accept that it’s their defect? I had one, my first program at my previous employer, we got to each milestone, we had like a hundred open defects. And people came to me complaining, “Well, I got rid of my defects. I fixed 50 of them and I transitioned 50 to every other defect. But it’s not fair Chris, because everybody else transitioned their defects to me last night. How am I supposed to…” But we’re a team. Don’t reassign the defect in the tool and assume they’ll accept it. Talk to them. Say, “I’m going to reassign these five defects to you. Do you agree that they’re yours?” Talk more than use the tool to communicate. I love Jama Connect. I love the risk management aspect, all the risk files. But if you are going to assign a risk mitigation to somebody, talk to them before you assign them.
Vincent Balgos: “What are some market and technology trends you see coming to the industry in 2024?”
Bijan Elahi: The big ones are Artificial Intelligence (AI) and Machine Learning (ML). A lot of medical devices are now deploying technologies that are based on AI and ML. And this has really created the challenge for risk management. In fact, we don’t know how to really completely answer this yet. This is an unanswered question. And the regulatory agencies, ISO experts, they’re all working on this. So, answering this question of how do we manage the risks of a medical device that is constantly changing? With current medical devices, if you want us to make a change to it, you’re supposed to submit something to the FDA. What about a medical device that is changing by the hour? It’s not really possible to keep making submissions. So, this is one of the challenges that’s happening in 2024.
Chris Unger: Yeah, that’s the obvious thing. I was a skeptic. People a long time ago said, “Are you doing AI machine learning?” And I kept responding with “No, it’s not ready. It’s not ready.” It’s ready. It’s coming. It’s now. It’s 2024. I wouldn’t say it’s a 2024 trend, it’s ongoing and continuing in cybersecurity. I mean, all these things are connected. That we want to network. Radiologists want to work remotely. It was a long time ago that somebody talked to us and said, “Look, this is great. I’m the head of a radiology network in northern Jersey. We’ve got five radiologists. And when people come to my clinic, I’ll do a quick read of every scan in my area, but I’m the liver guy. So, all the liver scans get sent to me. And somebody else is the head guy.
But that means a network, which means you’ve got huge network security. So, cybersecurity is just always going to get more and more critical. And we’ve never been liable. We’ve had hospitals come to us saying, somebody’s stuck a USB stick into your system and you let that virus go and it infected their network, but it went through your product. Why didn’t you protect it? And that was a huge malware. Whatever ransomware hospital costs more money than effective fiber is going to be way more effective.
Audience Question: “I was curious, looking at your workflows with the dotted lines, I recently debated whether usability engineering should be its own pillar containing risk, containing system requirements or embedded within the existing infrastructure for those. Do you have any pros or cons or suggestions on whether you should look at usability engineering independently as a whole? Or as part of the risk plan system requirements plan?”
Bijan Elahi: Usability engineering is very well integrated into risk management. It is its own discipline, and it has its own standard IEC 62366:2015. But a lot of its work products are very similar to an actual integration with an ISO 14971 workflow. So, I can’t say that it should be independent, but I say integrated with risk management.
Chris Unger: Yeah, I think it’s both and, not either or. As Bijan said, there’s a use analysis report that is mandated. So, it’s its own discipline and it’s part of everything. It’s part of workflow. Remember I said, “Gee, we want, custom things that are easy to use. No training needed, just use it.” And that’s a customer value. It’s part of marketing. Think about reliability. So, if I take this and I drop it… what are the stresses? How do I test this stuff? It’s part of uses. When we did things, it was probably two-thirds of our reliability issues were unexpected use cases. So, we had this baby warmer, and it was in Philadelphia, so they had cobblestone streets, and they were just transporting it from one wing of the hospital to the other, no baby in it. And there was an infrared warmer, it went over it and the interim warmer fell over to where the baby would be. Because it was doing a shake test going over the cobblestone. And we didn’t think about that.
Another case we had a mobile X-Ray. Takes an X-ray system, moves it into the surgery, into the ICU, the recovery room. And it’s a battery… It was probably 600, 700 pounds. Great when you have this big hulking tester and they move it over this expected ramp, something like this was easy to move it over. You get 110-pound nurse in a hospital with a two-centimeter step going into the elevator and guess what? The only way they could get over the ramp was to take a running start and use the momentum. We had wheels falling off. What was that? So, we went to the hospital and watched them. Oh! We expected like 5 Gs and the upper limit (UL) is like 50 Gs or 10 x factor plus 200 Gs. Once we designed for 200 Gs, wheels stopped falling off. So, usability is part of reliability engineering. So, it’s part of everything and it’s used in analysis report.
Audience Question: This is a more general question, but for companies that have two or more variants of a product, what are your recommendations? And this is to both of you about managing both product development and product assets. So, let’s say 90% of the assets are common across three variants and how to handle risk management when the clinical usage of those three variants could be different?
Bijan Elahi: With respect to risk management. EU MDR allows you to do risk management for a family of projects. So, if this is a family that are very similar, you can do a common risk management and then do differential risk management for the differences between them to submit.
Vincent Balgos: I’ll also add that varying management configuration is a hot topic within the medical, especially as you build family of products and then you build your… Let’s say child products off that. How do you reuse and share some of that information for efficient product development? So, this is where Jama Software is really a great, unique opportunity where we’ve actually learned from other industries, particularly in automotive and in terms of how they deal with those different types of variants. So, we’re incorporating some good practices off the bat and again, happy to talk with each of you, especially if there’s specific questions on how to solve some problems.
Audience Question: My question is about integration. I mean we see more and more devices now have the ability to work together with solutions from other vendors. How can we can be prepared for that? I mean sometimes if your product is on the market, and somebody wants to use it and integrate it with a different solution. How can we be prepared for that from both a system engineer design perspective and for risk management?
Chris Unger: System engineering is kind of simple. Keep a configuration compatibility matrix to ensure that this version of your product is compatible with what version. And then really think through the use cases. The rainy day and sunny day. We had cases where our monitoring central station… So, we built some temperature monitors, fetal monitors, cardiac monitors, but we also then built a central station that have to work with our sensors but anybody’s sensors in the world. And we did pretty good with that.
We had a recall where somebody would plug in a… I forget what it was… temperature monitor? But it was a safety-critical device in the intensive care unit, and we didn’t have a fast enough response that it was plugging in. Usability. So, the nurse pulled it out, put it in again, pulled it out, and put it in again. And finally, the system had a race condition. It said you pulled it out, and when they put it in it tried to reset. So, the nurse had thought that it was plugged in it, and it wasn’t. And so, the nurse was assuming that the patient’s heart rate was monitored when it wasn’t, we had to recall the entire product. So have a standard interface. Have a compatibility matrix and test the unusual customer uses.
Bijan Elahi: With respect to risk management, if you’re making a medical device that is supposed to work with other medical devices together, then the together becomes a system. The patient is experiencing the risks that could come from the integration of all the devices that connect with your device. To manage the risk of that, what you need to know is which devices are going to plug into your device and then you test them to make sure that they’re safe together. And then you make a list of approved compatible devices that could be used with your device and your manufacturer makes another device that wants to be used with yours and you must check that too. Just keep expanding your list of approved devices.
In this blog, we recap our eBook, “An In-Depth Guide to IEC 62304: Software Lifecycle Processes for Medical Devices” – Download the entire thing HERE.
An In-Depth Guide to IEC 62304: Software Lifecycle Processes for Medical Devices
In the world of modern medicine and healthcare, software plays an integral role in the functionality, monitoring, and management of medical devices. These software components can range from simple interfaces to complex algorithms that drive critical medical decisions.
Ensuring the safety and effectiveness of these software components is of paramount importance, leading to the creation of standards such as IEC 62304, which defines lifecycle requirements for medical device software.
Understanding the Importance of Software in Medical Devices
Medical devices have evolved significantly, integrating software into their core functionality. From pacemakers to diagnostic equipment and even mobile health applications, software contributes to accurate diagnoses, patient monitoring, and treatment delivery. This integration enhances the capabilities of medical devices but also introduces potential risks if not developed and maintained properly.
Overview of IEC 62304
IEC 62304, titled “Medical device software – Software lifecycle processes,” is an international standard that provides a framework for the development of quality medical device software. It establishes standards for managing software development, verification, validation, and maintenance within the context of medical device development.
This eBook delves into IEC 62304, its components, implementation strategies, and benefits, equipping readers with a comprehensive understanding of how to develop medical device software that adheres to rigorous quality and safety standards.
Scope and 2 Application of IEC 62304
What Medical Devices are Covered?
IEC 62304 applies to a wide range of medical devices that incorporate software – software that is a medical device on its own (SaMD) or an integral part of another medical device (SiMD). This includes both standalone software devices and software that is part of a larger medical device. These devices encompass everything from simple mobile health apps to complex medical imaging systems.
Examples include clinical decision support software, manufacturing software used to test the delivery volume of an insulin pump, software used to analyze genetic data, software in pacemaker, etc.
What Types of Software are Included?
The standard encompasses software used for medical device design, development, production, installation, and servicing. This encompasses not only the software that directly interfaces with the patient or provides a medical function but also the supporting software used in manufacturing and quality control.
Key Concepts and Terminology
Software Safety Classes
IEC 62304 introduces a classification system based on the potential harm caused by software failures. The requirements vary depending on the software safety classification There are three classes:
Class A: No injury or damage
Class B: Non-serious injury
Class C: Serious injury
These classes help determine the level of rigor required in the software development process.
Software Lifecycle Processes
The standard outlines processes that span the entire software lifecycle, including planning, requirements analysis, design, implementation, verification, validation, and maintenance. Requirements vary depending on the software safety classification.
Software Safety Requirements
Ensuring the safety of medical device software involves identifying and addressing potential hazards. IEC 62304 mandates an increase in rigor of design control processes and documentation based on the software safety classification.
Software Items
Software items are software components that make up medical device software. By decomposing software into discrete software items, the manufacturer can analyze
failure points and interfaces. It also allows the manufacturer to independently classify and document these subcomponents, thus facilitating the possibility of
reusing these subcomponents in future products.Properly managing these items ensures traceability and facilitates risk management.
Complying with IEC 62304 significantly enhances software quality by providing a
comprehensive framework that guides the development, maintenance, and validation of medical device software. By adhering to its guidelines, teams are compelled to follow a structured approach, resulting in improved software quality. The standard mandates clear documentation of requirements, architecture, design, and verification activities, which in turn fosters transparency and traceability throughout the software development lifecycle.
This meticulous documentation ensures that potential issues and deviations are identified and addressed early, reducing the likelihood of defects and vulnerabilities making their way into the final product. The standard forces manufacturers to consider not only how they will develop the software, but also considerations for maintenance and the end of life of the software. Consequently, software that complies with IEC 62304 exhibits higher reliability, safety, and overall quality, which are very important in the context of medical devices where patient safety is paramount.
Furthermore, IEC 62304 references rigorous risk management practices (such as ISO
14971 principles), leading to the identification and mitigation of potential hazards associated with the software. IEC 62304 concentrates on the software development lifecycle, process, and documentation. The standard necessitates the classification of software components based on their potential risks, facilitating a targeted approach to testing and validation efforts. This risk-driven approach helps allocate resources effectively, concentrating efforts on the most critical aspects of the software.
Additionally, IEC 62304 requires you to have a plan for verification and validation of software. Different regions may have slightly different requirements. For instance, FDA has published “General Principles of Software Validation” Guidance.” These verification and validation activities are vital for identifying and rectifying bugs, security vulnerabilities, and functional issues. By conducting thorough testing and verification activities, software developers can enhance the performance, reliability, and stability of their products, contributing to an overall elevation in software quality.
Enhanced Patient Safety
Compliance with IEC 62304 plays a pivotal role in elevating patient safety thanks to the rigorous guidelines that mandate a systematic and controlled approach to software development, emphasizing risk management and mitigation strategies. By requiring thorough assessment of potential hazards associated
with medical device software, IEC 62304 ensures that developers identify and address safety risks early in the development process. This proactive approach results in the implementation of appropriate controls and safeguards, minimizing the chances of software-related failures that could jeopardize patient well-being.
IEC 62304’s emphasis on documentation and traceability further bolsters patient safety. The standard mandates comprehensive documentation of software requirements, design specifications, and verification and validation activities. This level of transparency enables regulatory bodies, medical professionals, and device users to thoroughly assess the software’s functionality and safety features. In the event of an issue or concern,
standardized documentation facilitates swift identification of the problem’s root cause, enabling prompt resolution to prevent potential harm.
Additionally, by adhering to IEC 62304, developers create a foundation for ongoing software maintenance and updates, ensuring that any changes are managed
systematically and with patient safety in mind. Overall, IEC 62304’s structured approach to software development and its focus on risk management and
documentation significantly enhance patient safety by reducing software-related risks and facilitating effective issue resolution in medical device software.
Regulatory Compliance
Regulatory authorities worldwide, including the FDA and the European Medicines
Agency, recognize IEC 62304 as a reliable framework for the development of safe
and effective medical device software. By adhering to its standards, developers
align their practices with established industry standards, which simplifies the
process of obtaining regulatory approvals.
One of the key ways IEC 62304 aids regulatory compliance is through its emphasis
on risk- based development and design controls. The level of rigor depends on the
safety classification of the software. This aligns well with regulatory expectations, as authorities often require comprehensive risk analyses to assess the potential impact of software-related hazards on patient safety. IEC 62304’s risk-driven approach not only helps in identifying and mitigating risks but also provides the necessary documentation for regulatory submissions, demonstrating that thorough risk evaluations have been conducted and appropriate controls are in place.
IEC 62304’s structured development lifecycle, which includes phases for software
planning, development, verification, validation, and maintenance, aids regulatory
compliance by providing a clear and consistent roadmap. This ensures that essential development steps are followed and documented appropriately. Regulatory agencies often scrutinize these aspects during the approval process, and adherence to IEC 62304 greatly assists in demonstrating that all necessary
processes have been carried out systematically.
Software Development Planning: This phase involves creating a comprehensive plan for software development that outlines roles, responsibilities, and the overall approach.
Software Requirements Analysis: Identifying and documenting software requirements, including functional and non-functional aspects, lays the
foundation for development.
Software Architectural Design: Designing the software architecture defines
how components will interact and ensures that the software can meet its
intended purpose.
Software Detailed Design: In this phase, detailed design specifications are
created based on the architectural design, providing a roadmap for
implementation.
Software Unit Implementation and Verification: Developers write and test
individual software units, verifying that they meet the defined requirements.
Software Integration and Integration Testing: Units are integrated into a
cohesive whole, followed by testing to ensure they work together seamlessly.
Software System Testing: The entire software system undergoes rigorous
testing to identify and rectify defects.
Software Release: The software is prepared for release, including packaging,
documentation, and any necessary regulatory submissions.
Software Safety Classification
Class A: No Injury or Damage Class – A software failures are unlikely to cause any injury or damage to the patient or user. An example might be a display error that does not affect the device’s functionality.
Class B: Non-Serious Injury – Class B failures could potentially lead to non-serious injuries, discomfort, or inconvenience to the patient or user. An example
could be an incorrect alarm sound that causes temporary stress.
Class C: Serious Injury – Class C failures have the potential to cause serious injuries to patients or users. For instance, incorrect dosage calculations by a medical infusion pump fall under this class.
G2® Once Again Names Jama Connect® the Overall Leader for Requirements Management Software
Jama Connect® was again named far and away the overall leader in the Winter 2024 G2 Grid® Report for Requirements Management Software!
In addition to the honor of being named the leader in requirements management software, we are proud to showcase that we were awarded several additional medals for Winter 2024 in requirements management, including:
Leader
Enterprise Leader
Momentum Leader
EMEA Leader
Small-Business Leader
Mid-Market Leader
Users Love Us
Download the full report to see why customers love using Jama Connect for product, systems, and software development.
Learn More About the Winter 2024 G2 Grid for the top Requirements Management Software productsHERE!
Jama Software® is honored to be acknowledged as the top requirements management solution. We’re grateful to our customers for sharing their valuable feedback on their experiences using Jama Connect. The “Users Love Us” category, in particular, is a testament to the value our industry-leading requirements management software brings to our customers, and especially for customers who have moved from a document-based approach to complex product, systems, or software developement.
“Product Design teams need a requirements management tool like Jama [Connect.] Using Jama Connect allows our software development team to have a well-organized and well-written set of requirements. It allows us to more easily maintain a baseline of features in our continuously evolving software.”
-From review collected and hosted on G2.com, Mark M. — Mid-Market
We strive to provide our customers with the best experience while using our platform. Being named as Leader in particular shows how much our users enjoy working within Jama Connect.
“Jama [Connect] is the final death blow to your grandfathers way of managing text based requirements.”
-From review collected and hosted on G2.com, Mark M. — Mid-Market
From all of us at Jama Software to all of you, thank you!
G2 scores products and sellers based on reviews, gathered from their user community, as well as data aggregated from online sources and social networks. Together, these scores are mapped on their proprietary G2 Grid®, which can be used to compare products, streamline the buying process, and quickly identify the best products based on the experiences of your peers.
Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from Innovation News Network, titled “Why penetration testing is critical to every robust cyber security strategy” – originally published on November 2, 2023.
A big “Thank You!” to Chris Dickens for a great article. As part of our security program here at Jama Software, we have a layered approach to security tests and scans. Scans are done on every build, automated tests are run on every build, and active PEN tests are done multiple times per year. As the only SOC 2 Type 2 product in the space, we have set a high bar for ourselves because we know the importance of security to our customers.
Why Penetration Testing is Critical to Every Robust Cyber Security Strategy
Chris Dickens, Senior Solutions Engineer at HackerOne, outlines an effective penetration testing strategy.
Digital transformation has become an essential requirement for any business that wants to remain competitive in an increasingly digital global landscape.
However, it’s not always straightforward. In many cases, digitizing key processes can expose businesses to a wide array of new cyber security risks they aren’t used to, potentially leading to damaging breaches, attacks and/or loss of sensitive data if they aren’t careful.
In order to protect against such threats, a well-rounded cyber security strategy needs to be put in place alongside any digital transformation initiative.
However, cyber security isn’t a ‘one and done’ activity, strategies must be continuously evaluated and tested to ensure they remain effective.
Cyber criminals constantly evolve their attacks, so cyber security must also evolve. Whatever works now will likely be outdated in just a few weeks or months.
One of the best ways to stay ahead is through regular penetration testing (pentesting), which can give companies a fast, accurate snapshot of the current state of their cyber defences. This point in time activity features ethical hackers putting themselves into the shoes of malicious actors in an attempt to breach a system’s security for the purpose of vulnerability identification.
Typically, both humans and automated programs are used to research, probe, and attack a network using various methods and channels known to be used by cybercriminals.
But too many still don’t fully understand how pentesting works, or how they can effectively implement it into their wider security strategy.
The era of secretive, closed-door penetration testing is a thing of the past. In those days, you had to depend on the skills and schedules of usually big companies, enduring long waits, and limited insight into the results and tester’s actions.
Nowadays, penetration testing has evolved significantly. It often commences within a few days and is typically conducted on a smaller scale more frequently. This transformation is credited to innovative platforms that offer real-time transparency into the testing process and a more inclusive approach when bringing testers on board.
The emphasis is now on results and experience from the ethical hacking community rather than formal education and certification. The creation of new AI-based hacking methods and willingness to test source code has also greatly improved the output.
While this may sound quite daunting for the business involved, pentesting is an incredibly effective way to discover major vulnerabilities in their security before they can be exploited, which is critically important for keeping sensitive data safe.
Arguably, penetration testing’s best advantage, however, is its thorough coverage and documentation. Due to its in-depth and refined testing, in most cases, vulnerabilities are discovered and documented, including details on how the bug can be exploited, its impact on an organisation’s compliance, and advice on how to remediate the issues.
Unlike other offensive security engagements, pentesting also allows organisations to test internal systems alongside unfinished applications – this is especially useful when leading up to a new product announcement or organisation acquisition.
Using pentests to inform both present and future security strategies
As mentioned, pentesting is a great way for businesses to gauge the effectiveness of their existing security defences at that moment in time.
However, too many organisations tend to treat it as though it’s the beginning and the end of the process, which it isn’t.
Pentesting is a tool, not a strategy, and as valuable as they are, pentests are only useful if the results are translated into an effective overall security strategy for the future.
An effective modern pentesting strategy should contain the following elements:
Establish key security priorities- First and foremost, businesses must determine what they need to protect. While it’s impossible to protect everything all the time, key assets should be prioritized based upon the damage the asset would cause if it was to be compromised. Typically, highly sensitive information such as proprietary IP, competitive and legal information, and personally identifiable information (PII) will be top of the list.
Get security buy-in from all employees- A sustainable security culture requires buy-in at all levels of an organization, from the executive board to the reception desk. If every employee takes responsibility for company security, it’s much easier to build a model where risks are shared, and teams across the company can scale securely.
Use pentesting as a regular security touchpoint- Regular penetration testing is a great way to promote a more proactive approach to security. All too often, organizations aim to meet only the minimum requirements for compliance – and believe themselves to be secure, which is a highly risky strategy. By contrast, combining regular pentests with bug bounty programs provides a continuous feedback loop that allows companies to quickly identify new vulnerabilities and deal with them before they come to the attention of malicious actors.
Make robust cyber security a strategic differentiator- A recent study by PwC found that 87% of global CEOs are investing in cyber security as a way of building trust with customers. If the lifeblood of the digital economy is data, its heart is digital trust. Organizations with a sound security strategy can quickly turn it into a strategic differentiator for their brand, which is invaluable in highly competitive business sectors and industries.
The best cyber security strategies can quickly adapt to change
Modern enterprise security is not easy. As more businesses embrace digital transformation and cloud computing becomes the new normal, reliance on IT is at an all-time high.
Consequently, even a small data breach can potentially have a devastating impact. On top of this, attack surfaces are exponentially larger than they were just a few years ago and continue to grow at an alarming rate.
The best practice approach for security teams is to color outside of the lines by infusing new and independent thinking. With this in mind, penetration testing offers much more than just a scan and definitely more than a tick-box compliance requirement.
By developing a cyber security program that employs an agile approach, organizations can prioritize flexibility and make rapid changes when needed.
Engaging ethical hackers enables organizations to deploy an army of specialized experts that will work around the clock to identify vulnerabilities and conduct pentests for both regulatory compliance and customer assessments. In today’s highly competitive and volatile business environment, few organizations can afford to forego such a crucial security advantage.
Contributor Details Chris Dickens – Senior Solutions Engineer, HackerOne
What is a Software Factory?
A software factory is not a physical factory; instead, it’s a metaphorical one, signifying a structured, systematic approach to software development. It’s based on the principles of manufacturing, where standardization, automation, efficiency, and quality control are paramount. In a software factory, software is produced in a manner akin to an assembly line, where each stage of development follows a well-defined process, ensuring consistency and scalability.
Standardization: Standardized procedures and equipment are the foundation of a software factory. Because of this standardization, the development process is more predictable and controllable since every piece of software is produced using the same set of procedures.
Automation: The software factory model’s foundation is automation. Automation tools are used to speed up development, minimize errors, and reduce manual labor from code generation to testing and deployment.
Modular Architecture: Software factories employ modular architecture in a similar way to physical factories that use interchangeable parts. Reusable components are made possible by this method, which speeds up and simplifies the development of new features or apps.
Quality Control: A software factory must employ continuous integration and deployment (CI/CD) techniques. By using these procedures, code modifications are automatically tested and released, upholding strict dependability and quality criteria.
Collaboration and Communication: Coordinating the efforts of the various teams participating in the development process requires the use of effective collaboration tools and processes. By doing this, it is made sure that everyone is in agreement and that the result meets the intended goals.
Benefits of a Software Factory
Increased Efficiency: By automating repetitive tasks and standardizing processes, a software factory significantly increases the efficiency of software development.
Consistency and Quality: Standardized processes and automated testing lead to more consistent and higher-quality software products.
Scalability: The modular approach and automation make it easier to scale the development process, accommodating more features or higher volumes of software production without a proportional increase in resources or time.
Faster Time-to-Market: With streamlined processes and automation, software factories can significantly reduce the time it takes to bring a software product from concept to market.
Cost-Effectiveness: Although set up requires an initial investment, the long-term benefits of increased efficiency and reduced manual effort result in significant cost savings.
Jama Connect® aids leaders by providing robust requirements and test management, ensuring clarity and alignment throughout the project. With Jama Connect’s Live Traceability™, teams can manage requirements and tests through the systems development process for proven reduction in cycle time and improved product quality.
With the advent of the software factory, software development has undergone a paradigm change from an artisanal, handcrafted approach to one that is more methodical, efficient, and scalable. Organizations can create software more effectively, more cheaply, and with higher quality by adopting the concepts of standardization, automation, modular architecture, quality control, and effective teamwork.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Steven Meadows, McKenzie Jonsson, and Decoteau Wilkerson.
In this blog, we recap our webinar, “Critical Alignment for Security, Safety & Product Development Team” – Click HERE to watch it in its entirety.
Critical Alignment for Security, Safety & Product Development Teams
Break down silos to unite teams for the future of vehicle technology!
Safety, security, and development teams tend to work in silos due to differing objectives, tooling, and methodologies; historical contexts; educational backgrounds; and even fundamental terminology.
The increasing interconnectivity of vehicles makes it hard to separate safety and security from development. In the complex world of software, teams must break down silos, foster collaboration, and streamline documentation to ensure agile development and adapt to evolving demands.
In this webinar you will learn:
Why it’s important to have compliance teams speaking the same language
What we’re seeing and expecting from the industry to bring these specialized teams closer
How to keep security, safety, and development teams aligned using Live Traceability™
How to avoid rogue development and keep track of progress with Traceable Agile™ practices
Discover how Jama Connect® can empower Automotive and Semiconductor development teams to improve their end-to-end lifecycle and avoid costly rework.
Below is an abbreviated transcript of our webinar.
Kevin Dibble: I’d like to talk about the agenda for today and focus on the word alignment because that’s where we’re going to cover how we bring together cybersecurity teams, safety teams, product development teams, and even project management.
There’s a lot of siloing and opportunities in organizations for these specialized groups to work separately. But we’re going to talk about the importance of bringing these teams together and show some enabling technologies around live traceability and traceable Agile practices. So that’s the focus for today. But first, let’s start with the problem, and I want to isolate safety and security to begin with. So how are teams working today in these two functional areas?
With the puzzle piece in the middle, I’m trying to communicate that these teams want to work together, but the puzzle doesn’t quite fit yet. So let’s look at some of the underlying reasons why.
First, with functional safety, the standards for functional safety in automotive, ISO 26262, has been around since 2011, and the safety work’s been around even longer than that. So for OEMs, tier ones, and even some tier twos, the organizational competency, processes tool, the culture of safety are quite mature.
But on the right side, we have cybersecurity, which in automotive is a new discipline, with new standards, new audits, and assessment requirements, and requirements coming very rapidly from OEMs and tier ones worldwide.
Dibble: These teams are going through training. The processes for doing product development according to standards like ISO 21434 are new or in development still. The discipline itself is new and transforming out of IT security. And so this helps to understand perhaps some of the underlying factors of why these teams might be working separately or not working exactly on the same page.
Which leads to a silo situation. And I’ve got functional safety on the right and cybersecurity on the left. Both of those standards and both of those disciplines require automotive V-Model development, with strict requirements for documentation, quality, and compliance with the V-Model.
And so what’s happening is that the organizations pulling together these disciplines along with product development are doing some sharing in risk analysis, and basically handing requirements to product development teams, and not yet in a stage where they’re fully collaborating. And that presents some problems. And it adds some risk.
A couple of examples here are both safety and security risk-based standards for understanding how we mitigate the risk of something wearing out like hardware or defects that could cause safety issues on the one. And then on the cybersecurity side, how do we mitigate the risk of an attacker using a threat to infect or change the behavior of a system?
The controls or the mitigations for those two types of risks might result in conflicting requirements. For example, how to handle a communication channel, and I’ve given you an example right here.
Those two teams have to work together along with product to solve those differences, as well as to build an integrated system that at the end of the product release cycle we’re not finding surprises in terms of conflicting requirements and implementations that don’t work together cohesively. And so that’s one of the areas cyber and safety silos can cause problems.
Dibble: Now, we’ve heard about safety issues, recalls, and unfortunately crashes and fatalities for years. But I want to highlight some of the things that are being written in the press even recently about the threats that cybersecurity is now trying to address. From taking control of fleets of vehicles to shutting down production lines to causing safety-related hazards potentially, these are very real threats, and this is why the industry is moving so quickly to adopt the new cybersecurity standard.
To be able to tie together the disciplines of safety and security as well as product development, communication is critical. These safety analysis and threat analysis can’t happen in a vacuum. The teams have to work together, and this is where that alignment concept becomes so important.
Also, both these standards, 21434 and ISO 26262 require the establishment of communication channels between safety, security, and other disciplines like quality. So the developers of these standards certainly were aware of the need for these teams to talk and to achieve alignment.
In this blog, we’ll recap our eBook, “What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security” – Click HERE to download it in its entirety.
What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security
A comprehensive guide to understanding ANSI/AAMI SW96:2023 and mitigating security risks
Introduction
Managing risk around a medical device’s entire lifecycle has become increasingly complex. Many devices use third-party components, which is especially true for devices that require a network to operate. This increased need for connectivity, along with other emerging threats, is putting security at the forefront of medical device industry standards.
A recent report titled “2023 State of Cybersecurity for Medical Devices and Healthcare Systems” found 993 vulnerabilities in the 966 medical products it examined—a 59% year-over year increase from 2022. Software applications, including those that medical devices relied on to work, accounted for 64% of the vulnerabilities found.
With device vulnerability increasing, new standards aim to keep up with emerging threats. As a result, ANSI/AAMI SW96:2023 was created to help protect against threats, understand risk, and guide manufacturers in taking the most appropriate actions to enhance security. However, because the standard is relatively new, many device manufacturers are still finalizing the interpretation on how this impacts their organizational processes. If you’re still working to get familiar with the standard, we’ve created a complete guide to make the task easier.
Third-party components may increase security risk, with one study finding that software alone accounted for 64% of noted vulnerabilities.
What is ANSI/AAMI SW96:2023?
ANSI/AAMI SW96:2023 guides security risk management for medical devices, aligning with the processes included in ISO 14971:2019.
The new standard addresses the entire lifecycle of a medical device, including areas such as design, production, and post-production. It’s intended for use with AAMI TIR57 Principles for Medical Device Security – Risk Management, which addresses cybersecurity analysis, and AAMI TIR97, Principles for Medical Device Security, which guides processes for managing medical devices in the post-market space.
The goal of the new standard is to support manufacturers in ensuring that medical devices are reliable, work as intended, and don’t cause harm to patients, operators, or the environment. It also focuses on mitigating any potential risks around device failure.
What is ANSI/AAMI
SW96:2023? The standard includes policies, procedures, and best practices designed to evaluate, control, and monitor potential risks involved with a medical device.
Security has always been important to medical device manufacturers, which is why considerations are included in ISO 14971:2019. However, ANSI/AAMI SW96:2023 aims to deepen security-related standards.
Addressing potential security risks throughout the entire product lifecycle, including design, production, and post-production, enables manufacturers to identify and mitigate potential risks through a more focused and proactive approach. It helps manufacturers continually identify, review, and safeguard against fast-evolving threats.
Understanding the security risk management process
As you get up to speed with ANSI/AAMI SW96:2023, the “security risk management process” section includes details for mitigating potential threats. It includes six major sections, everything from
security risk analysis to production and post-production activities. Each section contains a detailed framework, but for the sake of simplicity, we’ve highlighted a few main points for each.
The 6 Sections of Security Risk Management
Security risk analysis. It focuses on selecting product security standards, performing threat modeling, and establishing capabilities to identify and detect security vulnerabilities across a medical device’s entire lifecycle.
Security risk evaluation. Establishes a security assessment strategy and testing processes.
Security risk control. Identifies, designs, and implements security risk control measures, as well as verifying the implementation effectiveness of any security risk control measures.
Evaluation of overall security residual risk acceptability. Determine if the “security residual risk” of a device is acceptable.
Security risk management review. A security management report is prepared.
Production and post-production activities. Potential vulnerabilities are monitored to identify any new security risks. Also, it establishes processes to stay aware of new threats, creating security incident response plans and other measures to identify ongoing vulnerabilities.
Section 1: Security Risk Analysis
The security risk analysis focuses on selecting product security standards, performing threat modeling, and establishing capabilities to identify and detect security vulnerabilities across a medical device’s entire lifecycle. It covers:
Security risk analysis process: It suggests that manufacturers perform a security risk analysis, and the results are recorded in the “security risk management file.”
Intended use and reasonably foreseeable misuse: The “security risk management” file includes reference documents developed in compliance with clause 5.2 of ISO 14971. It needs to account for “the use of a medical device in a way not intended by the manufacturer, but which can result from readily predictable behavior.”
Identification of assets and characteristics related to security: You’ll also identify potential medical device vulnerabilities such as third-party components, hardware, and software.
Security risk estimation: You will estimate the associated “risks” for each of the identified security vulnerabilities and potential impacts on areas like confidentiality and integrity.
Section 2: Security Risk Evaluation
The security risk evaluation establishes a security assessment strategy and testing processes. A few areas it considers:
Evaluation of each security risk: Identify each security risk area, determining if a “security reduction” is required.
Evaluation of security risks with a potential safety impact: Consider every potential risk to determine any potential safety impacts.
This section is focused on identifying, designing, and implementing security risk control measures, as well as verifying the implementation effectiveness of any security risk control measures, including:
Security risk control option analysis: Determine if a security risk control measure is appropriate for mitigating security risks to an “acceptable level.”
Implementation of security risk control measures: Security risk measures are selected based on the prior step.
Security residual risk evaluation: After the security risk control measures are implemented, the manufacturer evaluates the security residential risk and records this evaluation in the security risk management file.
Benefit-risk analysis: If a security residual risk is found to be “acceptable” using the criteria created in the security risk management plan, and further security risk control isn’t practical, the manufacturer conducts benefits versus security risk analysis.
Risks arising from security risk control measures: The manufacturer reviews the effects of the security risk control measures to understand whether new security vulnerabilities and threats are introduced that could impact security, safety, or privacy.
Completeness of security risk controls: The manufacturer periodically reviews security risk control activities to ensure all vulnerabilities and threats are considered and security risk control activities are complete.
Section 4: Evaluation of Overall Security Residual Risk Acceptability
After the security risk controls are implemented and verified, the manufacturer determines if the overall “security residual risk” created by the medical device is acceptable.
Section 5: Security Risk Management Review
The standard recommends a review of the execution of the security management plan before releasing a new device. According to ANSI/AAMI SW96:2023, the review should ensure:
The security risk management plan has been appropriately implemented.
The “security residual risk” is at an acceptable level.
Methods are in place to gather and review details in the production and post-production phases, and leadership has reviewed and approved the plan.
Section 6: Production and Post-production Activities
The final section is focused on establishing, documenting, and maintaining a system to monitor, assemble, and review information about medical device security in the production and post-market phases. Also, it establishes processes to stay aware of new threats, creating security incident response plans and other measures to identify ongoing vulnerabilities.
2024 Predictions for Industrial and Consumer Electronics (ICE) Product Development
As the Industrial and Consumer Electronics (ICE) sector moves into 2024, we aim to gain a deeper insight into the factors driving transformation in the development of products, systems, and software and explore how teams within this sector are adapting to meet the challenges posed by these evolving complexities.
In part three of this six-part series, we asked our own industry expert Steven Meadows – Principal Solutions Lead at Jama Software®, to weigh in on the ICE product, systems, and software trends he’s anticipating in the coming year and beyond.
We like to stay on top of trends in other industries as well. Read our predictions for Automotive predictions HERE, Aerospace & Defense HERE, Medical Device & Life Sciences HERE, SoftTech HERE, and Product & Engineering Teams HERE.
Design Trends – What are the biggest trends you’re seeing in your industry right now? How will they impact ICE product development?
Steven Meadows: The Internet of Things (IoT) continues to remain at the forefront of development across consumer electronics manufacturing. ‘Smart’ products like home security systems, laptops, kitchen appliances, and tablets are manufactured with an increasing number of sensors and inputs that transfer data to different networks and applications. With more complex and integrated systems, the need for digital product development tools to ensure product quality is becoming increasingly important.
We’re seeing a shift in oil and gas companies managing requirements from documents to digital solutions. Increasingly complex projects that incorporate the setup of facilities and adherence to multiple standards have made this shift a priority.
Cloud computing, as we wrote about last year, continues to grow across the software industry. Cloud is the golden standard, allowing for more flexible, cheaper, and sustainable solutions. More and more companies increasingly rely on cloud computing for projects and daily activities without the need for managing system administration, upgrades, and security.
Biggest Challenges – What are some of the biggest challenges you think ICE companies will be working to overcome in 2024?
Meadows: Artificial Intelligence (AI) has been at the forefront of development for years and continues to evolve, allowing for more automation, self-maintenance and diagnosis, and other areas which have improved end products.
One challenge I see for industrial and consumer electronics companies to remain competitive is incorporating AI in their products to help with less costly maintenance and production lines. AI-assisted firmware development will help with this.
Regulations – What changing regulatory guidelines do you anticipate having an impact on companies in 2024?
Meadows: I have attended several conferences this year across different industries and it’s safe to say that more regulatory guidelines around artificial intelligence will be released and impact companies in 2024. This will certainly have an influence on product development and what companies can include in their products. It will be interesting to see what guardrails the government and other entities will enforce.
Tool Innovation – From an ICE engineering toolset perspective, what are some of the processes you think forward-thinking firms will be working to leverage or incorporate into their process and why?
Meadows: We’re seeing several trends across industrial and consumer electronics development. Companies at different scales, from startups to large enterprises, are placing a greater emphasis on maturing effective internal development processes and tools.
Requirements authoring has often been challenging for teams with differing experiences. Poorly defined requirements often lead to poor products and systems, more defects in the field, and costly recalls. Companies are embracing AI and machine learning in their toolset to help teams author better-quality, less ambiguous, and easily testable requirements. By applying the industry’s best-known methods for evaluating and recommending improvements across requirement statements, including the Easy Approach to Requirement Syntax (EARS) and International Council on Systems Engineering (INCOSE) guidelines, companies are noticing significant improvements with products being shipped to customers.
Our customers continue to see the value in shifting their product development process, enabled through a document-centric process, to a modern digital solution. With Live Traceability™ – and all development artifacts housed in a single source of truth inside Jama Connect® – development teams benefit from a real-time view of related artifacts and development activities. This is enabling our customers to reduce risk early on, speed time to market, as well as improve product quality.
What advice would you give to new companies entering the ICE industry?
Meadows: Make sure you place an emphasis on solid product development processes and tooling early on, even at the prototype stage. Your ideas may be great but unless you have an effective development process defined early on with the right tools to enable it, your products will ultimately suffer, and you’re introducing unnecessary risk.
In this blog, we recap our webinar, “DO-326 Airborne Security Assurance, Threat Modeling, and DevSecOps” – Watch the entire thing HERE.
Cyber vulnerabilities can have a significant impact on safety-critical systems.
Today there is an unprecedented level of digital interconnectivity in everything from vehicle sensors to rovers on the surface of Mars. The aerospace industry has a high degree of cyber connectedness where a negative impact could cause harm to not only aircraft but financial systems, company reputations, international relations, or even physical harm to humans and property.
During this informative session, Cary Bryczek, Director of Aerospace & Defense Solutions at Jama Software®, discusses how Jama Software applies a cybersecure-by-design approach to meeting DO-326A/DO-356A for aircraft systems and how this can be extended to the defense domain.
In this webinar, we covered:
Applying the Airworthiness Security Assurance Process
Threat (attack) modeling methods
Tracing security measures to requirements and tests
The role of requirements in DevSecOps tool ecosystems
DO-326 Airborne Security Assurance, Threat Modeling, and DevSecOps
Cary Bryczek: What we’re seeing today is just an unprecedented level of digital interconnectivity in seemingly every system out there. The aviation industry has a high degree of cyber connectedness where a negative impact could really cause harm to not just humans and property, but company reputations, international relations, or financial systems.
What we’re going to see today is how Jama Connect can provide a cyber secure-by-design approach to meeting the many aspects of DO-326 and DO-356, or ED-202 and ED-203 in Europe, the Middle East, and Africa (EMEA.) What we’re going to see is we’re going to apply the airworthiness security process that’s inside of DO-326, and use Jama Connect’s Live Traceability™ to trace security measures to security requirements, trace security requirements to testing, look and see how a threat analysis can all be incorporated into a single platform.
What is Cybersecurity by Design? So one of the things that we see a lot is in the tool ecosystem is a very disconnected set of processes and tools. So whether you’re tracing and using tools that do requirements identification, tracing those to verifications and hardware and software designs, or whether you’re using tools to do aircraft security analysis and tracing those to security architectures and security V&V, we’re noticing the disconnectedness of the processes in the tool ecosystem is causing product delays, cost overruns, product failures, audit failures, late identification of defects, and lack of visibility because the ecosystem is very disconnected, is taking place. There’s poor requirement coordination. Change management is hard between software and hardware, and you have a high degree of manual effort required to produce the traceability that’s required for certification. And you’re seeing this after the fact and Excel is used everywhere. Desktop tools are prevalent in the engineering of these systems, and it’s difficult to integrate desktop tools and Excel files into and across the ecosystem for product development.
Bryczek: So what is Live Traceability? Live Traceability in Jama Connect gives the ability for any engineer at any time to see the most up-to-date upstream and downstream information for any requirement, no matter the stage of the systems development or however many siloed tools it spans. Now, this Live Traceability is important because it’s required by the industry standards like we’ve seen in aviation development and Live Traceability delivers a huge productivity improvement and it reduces the risk and the delay that happens when you have a disconnected tool environment.
So we’re going to talk about DO-326. DO-326 is really a set of standards jointly developed by RTCA and EUROCAE. It came about in 2006. It includes a few separate standards. DO-326 and ED-202 really is about the airworthiness security process specification. It explains the fundamental concepts behind airworthiness cybersecurity. DO-356 and ED-203, the airworthiness security methods and considerations, this explains how to perform cybersecurity investments, how to evaluate threats, and security measures of the system. How do you apply the mitigation measures? DO-355, we’re not going to really talk about that one today, but it’s applicable to if there are changes in an already certified system. So one of the most relevant documents you’re going to start with even before you start down the path for cybersecurity, is creating your product information and security risk assessment document. You’re going to perform an analysis of this, and this analysis should be conducted according to the standards.
So what exactly is airworthiness? So airworthiness security is the protection of the airworthiness of the aircraft from intentional unauthorized electronic interaction. So existing safety processes don’t consider intentional disruption. They look at the faults and failures of an aircraft or the aircraft system on a whole. But DO-326 is specifically looking at intentional human-initiated actions with the potential to affect the aircraft due to some unauthorized access or disclosure or causing some denial or disruption of the information systems, the networks, and the software that’s running on these aircraft systems. So this also might include things like malware or infected devices or the logical effects of any external systems. So the purpose of the airworthiness security process within DO-326 is to establish that when subjected to this unauthorized interaction, the aircraft is going to remain in a condition for safe operation.
So like I said earlier, DO-326 describes the what and DO-356 is the how. I’m sure that you guys have carefully looked at both of these guidelines and these are images from the guidelines. But I just wanted to point out what we’re going to talk about today. We’re going to talk about how the airworthiness security process and threats are mapped in Jama and how you can have security assurance and the risk assessment process from DO-356, how those can be conducted in Jama Connect itself. As you know, DO-326 live in its own. You’re having supporting processes from the development of the aircraft, the development of the system, DO-178, ARP-4754 are all interacting and being conducted at the same time. So there’s no linear, do this first, do this next, do this later. All of these processes are taking place pretty much simultaneously or iteratively as you design and develop the aircraft system.
So the airworthiness security process from a basic level, it’s again, it’s the protection of the aircraft from intentional unauthorized electronic interaction. There are four steps for the basic process. We’re going to first identify the system assets and its parameters. The second step is to identify the threats for all of those assets, identify those risks for each of the threats, so what might happen, and then create controls and mitigations for those risks. You’re going to be adjudicating the degree of harm and assigning a security assurance level, the strongest being SAL3 or the least would be a SAL zero where there’s this limited or protection needs required. So there’s a way to grade those as well.
Bryczek: The inside of Jama Connect itself, this image describes essentially the architecture of what you’re going to see that what we have in the product. We have a template that you can use to facilitate this. It sits alongside of our template that’s used for ARP-4754, and DO-178, or DO-254. The orange assets essentially is the data model that we’re using to capture the different types of things in the system. So we have assets, we have vulnerabilities. Those are tied to different threat assessments or a threat assessment is performed on these types of objects. We have security measures, we have the security architecture elements, and those feed into the security requirements. This comes pre-configured out of the box. We also have an area where you going to capture the data for that kind of thing.
Having this sort of a data model enables engineers to really perform the analysis to understand, all right, which assets have I not assessed yet? What’s the workflow? Who has reviewed the threat assessment? Have the security measures been satisfied by security requirements? Have we done security testing of the system? So this sort of data model enables the traceability to be instantiated and allows engineers to really more easily create the kind of a content. So one of the benefits you see of using Jama is that the security process is not disconnected from the design and development of the aircraft system itself. It’s done alongside. So that way you have that earlier touch points between the functional aircraft, design engineers and the security engineers. So you’re building in that secure by design approach.
![[Webinar Recap] Critical Alignment for Security, Safety & Product Development Teams](https://www.jamasoftware.com/media/2024/01/Copy-of-compliance-made-easy.png "[Webinar Recap] Critical Alignment for Security, Safety & Product Development Teams")
![[Webinar Recap] DO-326 Airborne Security Assurance, Threat Modeling, and DevSecOps](https://www.jamasoftware.com/media/2023/12/DO-326-Airborne-Security-Assurance-Threat-Modeling-and-DevSecOps-2.png "[Webinar Recap] DO-326 Airborne Security Assurance, Threat Modeling, and DevSecOps")