This conference call transcript was computer generated and almost certianly contains errors. This transcript is provided for information purposes only.EarningsCall, LLC makes no representation about the accuracy of the aforementioned transcript, and you are cautioned not to place undue reliance on the information provided by the transcript.
spk02: Hello, and welcome to today's webinar, The Path to ISO SAE 21434 Cybersecurity Compliance. I'm Amanda Hosey, your moderator for this 60-minute program, which focuses on the fundamentals, requirements, and impacts of the ISO SAE 21434 standard. Our speakers today are Bill Mazzara of the SAE ISO Joint Working Group that published the ISO SAE 21434, and Fred Roberts of Synopsys. Fred Roberts is a senior manager of R&D at Synopsys, where he manages a team of cybersecurity engineers that have developed and released a fully ISO SAE 21434 compliant cybersecurity management system for the development of Synopsys IP. He has more than 25 years of design, verification, functional safety, and quality engineering experience. Bill Mazzara is a technical fellow of global vehicle cybersecurity who serves as chair of the SAE Vehicle Electrical System Hardware Security Subcommittee and is a member of the SAE ISO-SAE Joint Working Group for Road Vehicles Cybersecurity Engineering, which published the ISO-SAE 21434. He holds 29 patents and is a certified information system security professional. Bill holds a bachelor's degree in electrical engineering, a master's degree in wireless communications, and an MBA. If you have questions for our speakers, please send them through the ask a question box and we'll address as many as possible at the end of the program. Also note that a PDF of today's slides may be downloaded under the event resources tab. Now onto the presentation. Welcome Fred and Bill.
spk01: Hello.
spk03: So, I would like to set up the challenges that we sought to solve with ISO SAE 21434. Upon the formation of the committee back in 2016, we identified that there was a trend toward cybersecurity. The risk of cyberspace is growing, and so that is what led to the formation of our group and the structure of 21434. The 21434 is based on organizational policies, TARA-based thinking and project execution. It is not prescriptive of any specific cybersecurity solutions. But we want to talk about the trend toward software-defined vehicle and how it might apply there as we see a growing amount of development out of context. So the trend toward cyberspace is growing in the auto industry. The connected services to mobile customers make our vehicles a part of the Internet. But the vehicles themselves are also using these services for things that we would have previously thought of as fundamental driving capabilities. Automated driving features that depend on communications between vehicles depend on cyber technologies such as LIDAR, radar, camera imaging. All of this then leading to the EVs, these electric vehicles, which don't run on gas anymore. They need to plug into the smart grid in order to get the car the energy it needs for propulsion. All of this means that the automobile has become a creature of cyberspace. And cyberspace is not a friendly place. The automobile has joined a place that has formed now over decades with a lot of risks. The risks exist that you could see replacement of physical actuators with electric signals now in the vehicle. These signals replace hard wires now with interdependent networking. The data transmitted on that network is now interpreted by software rather than electrical circuits. The signals can be spoofed and tampered with, and the software itself may be modified. Furthermore, the data can be retained to improve operations. Well, that data is at risk of being modified, being tampered with in cyberspace. Lastly, with all that data, the data can be leaked. The leaked data itself may pose another threat to the vehicle operations in cyberspace. So this is what led us to the formation of the Joint Working Group. Back in 2016, we identified this trend in the industry. ISO and SAE formed a joint working group to collaborate together to create a standard. It is really one of the first of its kind where ISO and SAE internationally collaborated with more than 100 experts over 14 nations and 82 organizations to form this document. The document was ultimately published on August 31st of 2021. It is a new standard. It expands upon the basic framework that was developed by SAE J3061 and replaces that with a full standardized framework that can be used for the development of products in cyberspace. It is formulated to align with ISO 26262 so that the goal is that it is easily integrated with existing processes any entity in the industry may have. Furthermore, 21434 is built based on existing principles in the cybersecurity industry. It heavily leverages the NIST risk management framework that is available to any industry to deal with threats in cyberspace. The structure of ISO SAA 21434 is shown here. This is a snapshot from the document itself. The objective of 21434 is to build a process oriented toward the development of product in consideration of threats of cyberspace. Cybersecurity requires there to be organizational management structure and a cybersecurity management system in place as a part of the organization tasked with developing product. One of the points of 21.434 is to focus on product development, the interest of the road user in cybersecurity, and not to mix that with enterprise cybersecurity, which has its own sets of standards. The second set of work products within 21.434 out of Section 6 is that of project-dependent activities. This is an outline of the specific tasks that should be considered in building any product according to the cybersecurity management system set up in that organization. These are product development activities, and there is a recognition of the distributed ecosystem that automotive products are built upon. So there is a template for interface agreements that can be put in place up and down the supply chain as we deal with the tiers of automotive suppliers. Section 8 is a diversion into the continual cybersecurity activities, the expectations of activities throughout the lifecycle of the product. Sections 9, 10, and 11, 12, 13, and 14 go through a systems engineering process of product development activities to build this into product development operations in any organization section 15 is added at the end as a normative reference method to help instill a framework of threat analysis and risk assessment to be used as methods throughout the entirety of your 21-434 process. So the organizational policies are the foundation of 21-434. The point is that to set direction for an organization, to spend some time to sit in calm times when you're not under the pressures of a daily release or the threats of an ongoing incident or some kind of other stressful moment. Instead, to set up for your organization the rules to achieve the risk tolerance that is acceptable to that organization. One of the challenges we have with 21434 is that the risk tolerance level will vary greatly depending on the type of product and the image of that product the organization seeks to achieve. You know, it's not like safety. Safety has the luxury of gravity. Safety is always going to fail in exactly the same way and have the exact same expectations across the product portfolio. Here in cybersecurity, we need to set up rules to achieve a risk tolerance to an organization and establish the procedures that facilitate development aligned to those tolerances. It's not good enough to say, go ahead, go do the right thing. 21.434 expects a detailed set of organizational policies across several subjects that are outlined in Section 5 to outline all of the dimensions of the cybersecurity management system that are necessary to achieve the risk tolerance that is expected by that organization. Next, I skip to the end of the document. We have the TARA. In 21434, we debated a lot about where exactly this should fit in the document, because the idea is that the threat analysis risk assessment method is a foundation of thinking. It's a thought-based process that should go into the philosophy and methodology that is used throughout 21434. It sets up a common method of asset analysis to identify what needs to be protected or maybe what should have been protected, depending on the tense of which you're thinking about this. The damage scenarios of the stakeholders of interest of those assets and what it means to incur a loss to those products. Separately, we look at the attack paths that might achieve a plausibility of damage. The feasibility of damage. A realistic attack path that some modern adversary could actually follow. These two streams are then mixed together in a determination of risk. Risk is defined as the impact versus the attack feasibility. Something that is maybe feasible but has no meaningful loss to stakeholders is not a risk. Something similarly that could be an impactful loss but is not realistically feasible given modern technology and available equipment to adversaries is again not an actionable risk. So the whole idea of the TARA is to constrain risk into quantifiable terms to limit what we might have in scope. to address the needless anxiety, the anxiety that certainly you could build up from yourself if you spent a few days searching the internet and reading headlines of what might go wrong. Next, we look at the project execution within ISO SAA 21434 framework. 21434 is leveraging systems engineering principles. The idea is to write a plan and follow the plan. Use the TARA, as I mentioned, as a method of analysis throughout that plan. Select the risk treatment recommendations according to the policies that I started in the beginning that your organization has set to reach the risk tolerance that is acceptable to your company. Cybersecurity goals and concepts suitable for the project then need to be identified. According to those policies, this may require tailoring of specifications to an implementable cybersecurity specification. The major deliverable out of 21434 is work product 1001, which is the cybersecurity specification, ultimately defining exactly what needs to be done for a particular product to achieve a particular user story within a particular organization's acceptable tolerances. Then once the product is built, there needs to be verification and validation. Verification is the test to make sure the specifications are achieved according to the documented requirements. But validation goes a step further to also test the space around those requirements to again go back to those organizational policies to make sure that the risk tolerance has been achieved. All of this needs to be composed in a case to demonstrate the plan was This cybersecurity case becomes a document of due diligence, demonstrating to anyone who may ask in the future what was done to address the security of the situation that will get hacked. Notice I said will get hacked because we need to approach all cybersecurity with the presumption that we will eventually be hacked. And we need that cybersecurity case to show the demonstration of due diligence and thought processes that were put into the design when dealing with that hack one day that may happen once we've all moved on, retired, who knows this could be a decade from now that you're dealing with this attack. So next I want to slide into the discussion of development out of context. The industry is in a trend right now towards software-defined vehicles, where hardware is built in anticipation of a growing and ever-changing software that might exist on that hardware. No longer are we looking at building software with a very specific hardware set, where the software only runs on that specific hardware. And in building hardware, it will only ever execute the one set of software that it was purpose-built for. Customer needs are met in software. And in the future, we are seeing these updatable needs as needs and preferences change as the life of the product goes on. So, ISO SAE 21434 is very usable in this context. It is built to be used for development out of context. The idea that you might be building a piece of hardware with only some example anticipated needs of software. The final application is not known at the time the hardware is designed. The point of 21434 is it provides a comprehensive framework to provide that case of cybersecurity due diligence when the product is complete. All of the work products of 21-434 may be developed out of context, but the important point is when doing so, all the assumptions that needed to be made to fill out the full framework of work products need to be documented and then checked upon reuse. We call that reuse analysis. in 21434, where maybe when the final application is determined, analysis needs to be done to determine if those assumptions that were made in the development of context actually do still hold true. So, when looking at 21434, and as more of you are looking at software-defined vehicles and development out of context, I encourage you to look at the entirety of 21434, the whole framework And look to establish what is your documentation of assumptions that you would put in place in order to build your cybersecurity case for your product developed context. So, in closing, I want to offer to everyone the SAE training curriculum. We offer a training program that provides two different aspects of training. One, which is an older class, which is our webinar, shows how managing cybersecurity risks using 21-434 can be done. And the current class that we offer is an instructor-driven course, two levels of training that leads to a cybersecurity certification that individuals may take to get a certified knowledge base of the work products of 21434. By the end of C2107, I hope that all of the students can be familiar with and be comfortable enacting any of the work products outlined in 21434.
spk01: Thanks, Bill.
spk00: So now if you didn't know before, you understand what ISO SAE 21434 is and why you should care about it. Now what I'd like to talk about is what some best practices when implementing your own cybersecurity management system that would comply to the requirements of the standard. Now, one thing I wanted to mention that this is not, this is not an in-depth training on how to implement your own system. This is more of a set of best practices that we have discovered in our path to implementing a system that is compliant to the requirements of 21434. So we're going to look at this from a perspective of an element out of context, which is something that Bill should have been talking about in the previous sections before so you understand what an element out of context is. Just as a quick repeat, an element out of context is something that is designed without knowledge of the final system that it's going to be implemented in. And our conversation is going to focus on two areas of the standard. We're going to be talking from the organizational cybersecurity management section five and project-dependent cybersecurity management, section six. Now moving on to that topic, let's talk about organizational cybersecurity management best practices. So the first of those best practices that I would say is you want to make sure that you have commitment from management and not just commitment from management at the top level. You want to have commitment from management at all levels of the management chain. It's very important. Now, if you don't have that commitment, it's going to lead to a few different issues that you're going to struggle with. First of those is you're going to have inadequate resources. Invariably, you're going to have something come up where you're going to need people to be doing something that is not focused on cybersecurity. Having that commitment from management makes it an easier decision to say no. Cybersecurity activities are important, and we're not going to deprioritize them. And that's the next issue is you'll have a challenge establishing and enforcing the proper cybersecurity rules and processes that will help you to reproducibly develop your products to meet the requirements of the standards. Now, what does commitment do for you, though? Commitment facilitates several different things. First off, it helps to establish a strong cybersecurity culture. And a strong cybersecurity culture is going to help such that everybody in the design flow is going to be thinking about security first. So they're going to be making decisions early on when it's very less expensive to implement whatever in the design that you have that you would need to meet those requirements. Now, next is proper competence management. And what do we mean by proper competence management? Proper competence management means that you will have the right people doing the right things at the right time. And if those folks do not have the amount of training that they need, you make sure that they get the training so that they are able to do the job that you've set them out to do. And this is a requirement of the standard that you make sure that you have folks trained to do whatever it is that they need to be doing. Now we've talked about commitment. Once you've got commitment from management, next we would talk about prioritization of the cybersecurity activities, making sure that they happen at the right time in sequence. Many things that you would need to do early on in the project are easy to implement and will not be as easy to implement if you find them at the end of the project when you have to go back and do a rework of your architecture, of your design, or some other major thing in the project. Now that we've talked about the commitment requirements as a best practice, let's talk about establishing good cybersecurity development process formalize your cybersecurity development processes. Now, we don't know your designs. We don't know your design development environment. So we can't tell you how to implement a strong development process. But what I can do is tell you what we did when developing elements out of context. What are the things that we put in place? And hopefully this will help provide you with a template of some of the things that you can put in. First off, at the core of our processes is we've got a foundation of a strong quality management system. That quality management system provides the basis of all of the work that we do. We implement strong change management, making sure that any of the changes in the project are reviewed and implemented in such a way that they don't introduce undue risk. We have configuration management, making sure that all of the the things that need to be established for a project are established upfront, and the base development processes that our other processes extend. At the center of that, we have the cybersecurity policy, which establishes our base rules and names all of the processes we talked about before. And in the cybersecurity policy, we also have a strong statement of commitment from management. And as we talked about before, commitment from management is very important. The next key point or portion of the process framework is our security development lifecycle. These are the processes that guide the development of our engineering. And we implemented it as an overlay to our standard development processes. Anything that needs to be done specially, any cybersecurity controls that you need to implement as part of the design would be called out by your security development lifecycle. And we'll talk more about the security risk analysis process in upcoming slides, but this is a process that performs a structured risk analysis of the product and outputs a threat model that can be used by entities through the supply chain that would be integrating this product into their higher level design. And once you've got all of your development processes in place, and are ready to, and have folks following them, the next best practice is to make sure you enforce those processes. Don't just publish the processes and assume that these documents are out there and everybody's going to follow them. You need to actually keep people accountable. Follow through with process audits is how we've done it, and this is something that we inherited from our ISO 9001 certification, but we've used this to help ensure that the teams are actually following the processes and doing the right things at the right time. And this is different than the organizational audit that we've talked about or that the standard talks about before. This is actually audits that you would perform during the process and recommend that you do these at key points in the development flow. For example, how we do it at Synopsys is we have two key audit points. We have the readiness audit that's going to happen at the end of our architectural phase. You've captured all of your cybersecurity requirements in the planning phase. You've gone through the architectural phase, taken those cybersecurity requirements from planning and refined them into the architecture and made sure that they're in a state that is ready for implementation. And then we allow the implementation teams to move forward once all of the work products are in place. after implementation and you're ready to release we also have a follow-up implementation audit to make sure all the work products that needed to have been developed during the the implementation of the product have been complete and you're ready for release and one of the things that i'd like to talk about real quickly here before we move on is this can be conducted by an internal team that you build up yourself or you can engage with a third party that's going to be completely up to you, depends on the scale of your organization. However, one thing that I need to make very clear is that independence is key. You don't want the auditor to have any stake in the release or scheduling or whatever. Make sure that your auditors are independent. So that is organizational. We've talked about having a strong commitment. have strong formalized development processes and enforce those processes. Now let's go on and talk about the project-dependent cybersecurity management best practices. And the first of those best practices, I would say, is establish and document your cybersecurity roles and responsibilities. They're called out in the standard. 21434 indicates that you should have a definition of roles and responsibilities at the organizational level, but we really manage this at the project level as well. And these are the main roles that we call out specific to cybersecurity activities. We'll have an architect, a cybersecurity manager, analysts, and an assessor. And how do we manage it? We manage it using something that we call a team competence document. And this document is essentially a spreadsheet that calls out all of the roles of the project, who is filling out those roles, why are they competent to do the job, either by job experience, training, or a combination of the above. But this is something that gets attached to the project and lives through the project and is archived away once that project is done and released. One of the next things that we would want to talk about is adopting a strong requirements management system. And the standard talks about making sure that your cybersecurity specifications are traceable through to higher level requirements. But it doesn't really tell you how you should do this. And adopting a strong provide you with some benefits. First off, it meets the requirements of the standard. But second off, it'll help reduce risk because Manually tracing all of your requirements is something that's going to be very tedious and fraught with error. You also have a strong ability to manage your change control and follow traceability. So if you were to adopt a strong requirements management system, let's say you have your top level cybersecurity requirements that go through to the architectural requirements that go through to your design requirements. And let's say that the top level requirements were changed for some reason or another. a strong requirements management system will trace those requirements through to the lower level requirements and anybody responsible for the lower level requirements will understand that there is something that's changed that they need to address and they need to adjust for. Not much else to talk about on requirements management. The next Topic is implementing security risk analysis, making sure that you follow a subset of the Clause 15 activities. I know I'm talking about this in Clause 6, but this is the subset of Clause 15 activities that apply to an element out of context. And what would you want to do? You want to identify the assets, and these are the things in the design that you want to protect. In Synopsys, we've identified the idea of a conceptual asset versus a structural asset. Conceptual assets might be something like the car key, that secure string of characters that will unlock your car. Whereas the register, the piece of hardware that holds that would be the structural asset, which is really what you can protect and control in a hardware design. So the next step would be identifying the threat scenarios that would potentially affect that asset, would compromise the cybersecurity properties that you want to protect for that asset. Once you've identified those threat scenarios, you analyze the attack paths, understanding which path can realize that threat scenario. And once you've identified those attack paths, You provide a suggested, we call them mitigations, the standard calls them risk treatment, but they're really risk treatment recommendations. You provide the integrator who is going to take your element out of context and apply risk treatments to that. They can either accept, mitigate, or pass on that risk to their customer, or if they're the final entity, they make that final risk treatment decision. Moving forward, how do we handle risk treatment at Synopsys? We actually have a security risk analysis that we've stepped through that follows all of the asset identification through enumeration. And it produces a document that we provide to our customers that can be used by two separate audiences. The first audience is going to be the integrator at the customer side, the person that's going to be going through the design, making the decisions about what configurations they need to enable, disable, or set in the design as they integrate it into their higher level system, whether it's an SOC or what have you. And our document will discuss the the risks associated with that particular configuration item or option and provide suggestions, the risk treatment that we were talking about before. The other thing that comes out of this security risk analysis document is a threat model that would be used by the system level or higher security engineer who's developing a threat model for that SOC or that vehicle, what have you. These items would be getting So we produce a threat model that can be used at a higher level system. And how does this fit into the standard? The standard talks about release for post development. This is section 6.4.9. Discusses giving the integrator the recommendations related to any of the security considerations associated with that design and what those risk treatment recommendations are. And one of the things that I wanted to discuss, stepping back to the idea that we're talking about, an element that's developed out of context, is something that is identified out of context may or may not manifest as a vulnerability in the final product. Context is really going to matter. And let's take, for example, Bluetooth. If you were developing a Bluetooth IP that's going to be used by your customer, you don't necessarily know if something that you've identified as a potential issue is going to be a big deal for them or not. They are going to know that based on their context. So here, for example, many times Bluetooth is used for tire pressure management or monitoring systems, TPMS. particular issue could leak information about the tire pressure, maybe we don't care as much. Now, if this was a Bluetooth being used as a car key and it could potentially leak that secret cryptographic key that unlocks the car, well, that's a bigger deal. The thing is, is you won't know until you have that final context, the design that it goes into. And so we've talked about all of the technical style best practices. So the last best practice that I want to talk about is when interacting with your final customer. The standard discusses the idea of having a cybersecurity interface agreement between yourself and your customer so that you can divide up who's responsible for what. And I want to stop for a second and talk about the idea of tailoring. If you're familiar with the ISO 26262, and the idea of tailoring there. Tailoring is used a lot there, but in ISO SAA 21434, tailoring is a little bit different. Tailoring in ISO SAA 21434 is considered tailoring if you do some or do not do something that you're supposed to do and nobody else is going to do it. If you're skipping something because it belongs later in the supply chain, you're developing out of context and this activity does not apply to you, like creating a production control plan. Well, that's something that is not tailored. That's a distributed cybersecurity activity. So in the cybersecurity interface agreement, we would talk about your responsibilities, your customers responsibilities. In fact, this is a snapshot of our cybersecurity interface agreement. and any shared activities and responsibilities that you would have so that it's very clear between you and your customer. And the whole point of this slide, though, is not just having that interface agreement. It's also standardized on one. I would really recommend that you create your own cybersecurity interface agreement. And if you have off-the-shelf components, this is what we do at Synopsys. If you have an off-the-shelf component that has cybersecurity interface or cybersecurity requirements, we provide a cybersecurity interface report. which includes all of the assumptions of who would be responsible for when this IP is developed. And if a customer does not agree with that, then we might have a statement of work where we rework the IP based on their requirements. But the idea of having a standardized interface agreement will help you. You may end up having multiple different formats that different customers are going to want to support. And even if you still need to use their format for the agreement, you've thought through these things ahead of time, and it makes those conversations a lot easier.
spk01: And then I'd go to the summary.
spk00: We've talked about the organizational and project-dependent best practices when implementing a CSMS. And you can see that this is a lot of work. And you can reduce your risk associated with this type of work by using products that have been developed to meet the requirements of the standards. And Synopsys develops IP that is compliant to several different standards. We've got IP that meets the requirements of ISO 262. We're developing IP that meets the requirements of ISO SAE 21434, AEC Q100, and we develop all of our IP to a base quality management system that is audited and recertified on an annual basis. And as we've shown here before, Bill talked about what ISO SAE 21434 is. why you should care about it, and how adopting a structured cybersecurity management system can help to make sure that you meet the requirements of automotive development. ISO 21434 not only will satisfy the requirements of your automotive customers, it also satisfies the requirements of regulators. And we've also talked about several best practices that need to be put in place to help facilitate your ability to meet the requirements of ISO SAE 21434. We talked about some organizational cybersecurity management best practices, project dependent best practices. And the conclusion is that a structured ISO SAE 21434 development platform minimizes the cybersecurity risks. And we also want to remind that Synopsys is developing our IP to meet the requirements of the ISO SE-2434 standard.
spk04: Thank you.
spk02: All right. Thank you so much, Fred and Bill, for those presentations. Just as a reminder to the audience, you can still submit questions for our speakers through the Ask a Question box on your screen. But now we're going to take some that have already come in. And let's see, first up, Fred, to you. What does it mean for an IP provider to be ISO SAE 21434 ready?
spk00: Well, I can only speak from the perspective of a developer that creates elements out of context. And since not all the requirements apply and IP developed out of context won't be manufactured by the vendor. So any requirements related to manufacturing won't apply. But being 21434 ready means that you will have developed following a 21434 compliant cybersecurity management system, and you've produced all the work products that the next person in the supply chain will need so that they can securely integrate the element out of context into their system. For example, the threat model we discussed earlier that would include the recommended mitigation screening interface or any identified threat scenarios would be an example of one of those work products that you would need to have.
spk01: All right, great. Thanks so much for that, Fred.
spk02: Next up, back to you, Fred. If a customer already has multiple security mechanisms such as TEE, HSM, or Root of Trust, do they still need to apply ISO SAE 21434? Yeah, thank you.
spk00: That's a good question. So the short answer is yes. So TEE and HSM, they're ways of addressing a security need. but they're really outputs of a design process. 21434 addresses the requirements of the development flow to make sure that your cybersecurity requirements of the product are met. And unless these products were developed following a formal cybersecurity management system, how can we be sure that the TEE and HSM really meet their final cybersecurity requirements?
spk01: All right. Great. Thank you so much for that.
spk02: All right, Bill, here's a question for you. Are the vehicles on the road today at risk to the dangers of cyberspace presented here?
spk03: Yes, this is a common question I see is that we are presenting a lot of new methods, a lot of new procedures to address technology in cyberspace. And people come to the conclusion that maybe there is some now pre-existing risk built into the vehicles we've already produced, built into the products that are in our daily lives. Well, I point out that a lot of the products that we have today have not yet achieved the future that I set out at the beginning of this presentation. They're not autonomous vehicles. They're not electric vehicles. Or if they are, they're not participating in in smart charging systems so much of what you see in day-to-day is really not yet in scope something that we would in 21 434 called not cyber security relevant and what i i'm happy we have done as an industry is to put this whole framework in place and get this out here ahead of time so that engineers that are now working on these new technologies that i present can actually become trained ahead of time and address these risks before real customers are driving these cars. I do point out that no product will ever be completely cyberproof. You're in cyberspace. You're going to incur those risks. A big part of what 21434 presents is having a cybersecurity management system and readiness framework ready to act and respond to the hack that occurs. Even if that hack occurs on something that might have been designed prior to the instantiation of 21-434 at an organization, when that happens in the future, the organization will be well prepared to deal with it.
spk02: All right, great. Thanks so much for that, Bill. The next question says, development may be initiated without the final application understood, so the damage scenarios to stakeholders may be unknown. Can a 21434 TARA still be done?
spk03: Absolutely. This is a big part of why you see the 21434 TARA presented as multiple work products. and where you can focus on the work products that are appropriate for the development that you are doing. And you can fill in some of the other work products with some of the assumptions that you have put in place to the decisions that you have made in that product development. This may lead to product limitations. It may lead to stated integration instructions that would come along with your product so that the user of the product can do that reuse assessment when they apply the product to a context and can fill in the blanks, so to speak. But the point being is that they're not blanks. You had something in mind when you made that decision. Write it down. Write it down. Create the work product. The work product might be entirely created on assumption. But if it's communicated, the user of the product in the end can then make a decision based on the information that was used at the time of development.
spk02: All right, great, thank you. Off of that question, one attendee says, 21434 presents a single TARA method disjointed from the design process. I have seen many different methods presented in the industry on how to do a TARA, so why does 21434 present only one TARA method?
spk03: So I do got to say that we came to this conclusion as part of the development of 21434. Early drafts of 21-434 had separate sections for system development, hardware development, software development. There were other discussions about the life cycle of the product and how things may change. But as those differences were examined, understood, as the consensus implementation of what is the state of the art was agreed upon by the joint working group, We clearly came to the conclusion that there were not appreciable differences of the work products that are produced in these different contexts. So you may see different templates or different sequences or orders of operation, but the result is always consistent with 21-434. Section 15 of 21-434 makes a strong point to say that the sections need not be followed in order. You should create the work products as you achieve the information in whatever task you are undertaking. And so in the end, there aren't these differences that you're talking about, these different methods of TARA that are presented. They result in the common set of work products as outlined in ISO-SA 821-434. All right. Wonderful. Thank you.
spk02: Since the SAE classes are in two levels, is level one a prerequisite to take level two?
spk03: So level two does build on some of the knowledge of level one. And level one chooses to focus extensively on the TARA methods. So, it is something that is a buildup of knowledge, but we don't actually require you to enroll in level one if you're already comfortable with TARA methods and would simply like to see how this applies to the rest of the document and become comfortable with the creation of all the other work products. It is not a mandatory curriculum requirement that level one be taken first.
spk02: All right. Thanks, Bill. Good to know. Next up, Bill, someone asks, under development out of context, my organization would struggle to create assumptions to facilitate all the work products of ISO SAE 21434. So should we simply omit work products we can't achieve?
spk01: So I understand where
spk03: this person might be at, is that they're working in something that is out of context, that has a limited scope, and as they look through all the work products of 21-434, this becomes very far removed from what their specific work is on. I would first ask that person in that situation to look to their larger organization. Make sure that this is not something, another part of the company is handling and then have the opportunity to conform to your organization's cybersecurity management system and instead opt in what it is the company does in the larger context. But certainly there are small companies that probably don't have that larger context. And this is where it gets to that whole statement of documentation of assumptions. And that assumption might be short and sweet. You might very much document that you simply assume somebody else is doing this for you. And this is where the cybersecurity case and the work products of 21434 rely strongly on the cybersecurity interface agreement. So when you go to then provide that product to someone in a customer-supplier relationship, or when you go to contract a supplier that is going to be providing you a product, you need to have a good understanding of the work products where you are weak. Those things that you might be tempted to omit become an important part of your cybersecurity interface agreement. And so the assumptions that you instead have documented in place of those work products are things that you can delegate in the responsibilities of a cybersecurity interface agreement and be sure are created as you sell the product development out of context into a context, a specific context in a particular contract.
spk02: All right. Thank you, Bill. One last question before we go. Bill, are there some functions or operations that are more at risk and so need 21434 applied versus other functions? And then add to that, what constitutes the highest priority function or lowest priority function?
spk03: So this is a common motivation that I saw even within the joint working group that created the document. Looking for some way to say that there is an exclusion, that some group of functionality is low risk and not applicable and we just can omit 21-434 entirely. The problem is you're creating a paradox here. Without doing 21-434, how do you really know your operation is at low risk? So 21-434 is structured in such a way that you can make some easy exit paths so that many of the work products all become default or omitted or easily identified with assumptions when you follow 21-434. The two tools that I would point to is first to identify cybersecurity relevance. Remember, I introduced 21434 as applicable to cyberspace. If you're truly dealing with old physical systems, wires, cables, mechanical systems, 21434 does not apply. But you don't know that until you've done an asset assessment and you've actually picked apart the asset to identify where the cyber relevant components are and all the rest of the components that are not cyber relevant. So instead of saying that you've omitted 21434, you've started 21434 and shrunk the scope of cyber relevant components within your item definition, hopefully down to a smaller set. Then within those components, you begin the TARA process. you begin to identify where are your low-risk items. Low-risk items need not be addressed. One of the risk treatment policies would be acceptance. To say you have done the analysis, you have documented the low risk, you've documented some of the assumptions that contributed to the low risk, and even though those components might be cybersecurity relevant, you're not going to take further action. But already now you have a very complete cybersecurity case for those low risk items. And what's most interesting to me are the assumptions that you put in place to justify that low risk condition. And those assumptions should be monitored, should be reviewed and considered at every time that product is reused. If those assumptions don't hold true upon reuse of the product, reassessment is necessary. So I hope this shows how actually you're doing 21-434. You're probably never omitting 21-434. Even for those systems that you figured out were entirely not cybersecurity relevant, exist entirely outside of cyberspace, you already stepped a couple of steps down the path of 21-434 and had done the analysis to come to that conclusion. So I hope you can see how functions are never really omitted from 21.434. It becomes a part of all of your engineering processes.
spk02: All right. Thank you so much, Bill, for all that great information. Unfortunately, that is all the time we have today for questions. I would like to thank Fred Roberts and Ben Nazera, as well as our audience, for joining us today. And thanks to all of you who submitted questions. We'll supply the speakers with any we didn't get to so that they can follow up later. As a reminder, you may download a PDF of today's slides under the event resources tab on your screen. In just a moment, a survey will pop up. Please tell us what you thought of today's program by answering three quick questions. This webinar will be available on demand for the next year and an email will be sent to everyone who registered as soon as the archive is ready. Once again, thank you all for watching.
Disclaimer