{"id":76942,"date":"2024-04-25T03:00:04","date_gmt":"2024-04-25T10:00:04","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=76942"},"modified":"2024-04-24T15:56:20","modified_gmt":"2024-04-24T22:56:20","slug":"critical-alignment-for-security-safety-product-teams-in-automotive-development","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/critical-alignment-for-security-safety-and-product-teams-in-automotive-development\/","title":{"rendered":"Critical Alignment for Security, Safety, & Product Teams in Automotive Development"},"content":{"rendered":"
\"\"

In this blog post, we summarize our Whitepaper titled “Critical Alignment for Security, Safety, & Product Teams in Automotive Development”. Click HERE<\/a> to read the full Whitepaper.<\/p><\/div>\n

\n

Critical Alignment for Security, Safety, & Product Teams in Automotive Development<\/h2>\n

As automotive product development becomes increasingly complex with multiple standards for compliance, alignment between different teams is more critical than ever. Yet in many organizations, specialized teams such as cybersecurity, safety, product development, and even project management work separately. In other cases, teams may be dispersed across organizations or geographies, making alignment even more challenging. Is collaboration and alignment even possible within these complex environments?<\/p>\n

How Safety and Security Teams Become Siloed<\/h3>\n

On the safety side, the standard for functional safety in automotive, ISO 26262<\/a>, has been around since 2011, and the safety work has been around even longer than that. For original equipment manufacturers (OEMs), tier ones, and some tier twos, the organizational competency, processes, tools, and culture of safety are quite mature. Enter the cybersecurity side, which is a new discipline in automotive development. Cybersecurity has new standards, audits, and assessment requirements, and requirements are coming very rapidly from OEMs and tier ones worldwide. Cybersecurity teams are still going through training. The processes for doing product development according to standards like ISO 21434<\/a> are new or still in development. The discipline itself is new and transforming out of IT security.<\/p>\n

The differences between the two disciplines lead to siloed teams of specialists even though both of those standards and both of those disciplines require automotive V-model development<\/a>, with strict requirements for documentation, quality, and compliance with the V-model.<\/p>\n

As organizations strive to align these disciplines along with product development, they typically begin cross-communication by sharing vehicle-level risk analysis<\/a> and handing safety or cybersecurity top-level requirements to product development teams. While this is a good step towards effective collaboration, a lack of transparency and the ability to fully collaborate across teams and tools still present significant problems and add unnecessary risk. Both safety and security standards are risk-based. ISO 26262 addresses systematic and random hardware faults which mitigate the risk of harm to persons due to defects in the system or from hardware wearing out prematurely. On the cybersecurity side, the risk of harm to persons is measured in terms of safety, financial, operational, or privacy impact and addresses the possibility or risk of an attack to critical system assets by a bad actor.<\/p>\n

\n

RELATED WEBINAR: <\/strong>Effectively Managing Cybersecurity in Jama Connect\u00ae for Automotive and Semiconductor Industries<\/a><\/span><\/span><\/h4>\n
\n

The controls or the mitigations for these types of risks might result in conflicting requirements \u2014 for example, how to handle a communication channel such as vehicle to network (V2N) or vehicle to device (V2D). In this example, the safety and security teams must work together, along with product development, to solve requirements discrepancies and build an integrated system that works cohesively.<\/p>\n

Of course, automotive manufacturers and consumers have dealt with safety issues, recalls, crashes, and fatalities for years. Now that most automotive systems include cellular, Bluetooth, and other ways to connect into the vehicle, development teams and manufacturers need to consider and address cybersecurity issues. The surge in cybersecurity threats stemming from connected cars and the expanding software content in vehicles has prompted the industry to swiftly embrace the new ISO 21434 cybersecurity standard. This is evident in scenarios ranging from managing vehicle fleets to halting production lines and posing safety hazards.<\/p>\n

Effective communication plays a critical role in tying together disciplines of safety, security, and product development together. Safety analyses and threat analyses<\/a> can\u2019t happen in a vacuum. Teams must coordinate, communicate, and align to achieve a comprehensive development picture that fulfills every team\u2019s requirements. In fact, both ISO 21434 and ISO 26262 require teams to establish communication channels between safety, security, and other disciplines such as quality.<\/p>\n

If not identified early, conflicting requirements often result in costly rework. Typically, the safety and security teams each write their own requirements with limited interaction at different times in the product development cycle. Sometimes, cybersecurity requirements come late and conflict with safety requirements, causing rework late in the cycle after software has already been developed, tested, and integrated. That rework results in unpleasant surprises in schedules, retests, and additional costs.<\/p>\n

\n

RELATED: <\/strong> The Impact of ISO 26262 on Automotive Development<\/a><\/span><\/span><\/h4>\n
\n

How the Right Collaboration Tools can Improve Alignment<\/h3>\n

One trend driving teams toward better alignment and collaboration is the continual increasing complexity of software in the vehicles<\/a>. Standards such as R155 and R156 are driving cybersecurity adoption as well as software-supplied services into the car, ADAS, and AI. Continuous updates are driving unsustainable growth in the amount of software in the vehicle.<\/p>\n

The rising threat of cyberattacks, exacerbated by the integration of additional software into vehicles, is a key driver of cybersecurity adoption. The ISO 21434 standard seeks to address these new cybersecurity requirements, but because it\u2019s so new, the communication channels are not yet well established.<\/p>\n

\"This<\/p>\n

The OEMs are rushing to support cybersecurity, which throws cybersecurity players right into the middle of a massive increase in software development. The OEMs are bringing software in-house and building Agile software factories, and tier ones and tier twos are racing to comply.<\/p>\n

This diagram depicts the difficulty of adopting Agile software in automotive. In some cases, it\u2019s like running into a compliance wall.<\/h6>\n

\"This<\/p>\n

Some OEMs and tier ones are responding by picking and choosing the pieces of Agile they would like to implement. But these organizations are finding that it\u2019s difficult to develop embedded automotive software that\u2019s compliant with these standards in an Agile way, such as running Scrum with mini V-models.<\/p>\n

Alignment and visibility when rapidly developing software \u2014 and in a compliant way \u2014 is critical to bringing together product development, safety, security, and other teams. When Agile methodologies such as Scrum are implemented, there is a risk of accruing technical debt if safety, security, and product development are not harmonized, often due to the demanding documentation needs and heightened quality standards for stories and epics.<\/p>\n

\n

TO DOWNLOAD THIS WHITEPAPER IN ITS ENTIRETY, VISIT:
\n<\/strong>Critical Alignment for Security, Safety, & Product Teams in Automotive Development<\/a><\/span><\/span><\/h4>\n
\n