Threats versus hazards: The role of SAE J3061 in automotive software development
Hazards that can be caused by system failures are well understood by automotive software developers, but threats pose a different challenge. Threats related to cybersecurity can involve malicious intent, potentially making them more difficult to address than hazards, according to SAE International’s Surface Vehicle Recommended Practice SAE J3061. The document states that, “addressing potential threats fully requires the analysts to think like the attackers, but it can be difficult to anticipate the exact moves an attacker may make.” (See Figure 1.)
Applying SAE J3061 processes in tandem with ISO 26262’s formal development environment.
This dynamic also potentially expands the scope of development processes. The introduction of cybersecurity into a formal development environment, such as the broadly implemented standard ISO 26262, implies the use of similarly rigorous techniques into automotive applications that are not safety-critical—and perhaps into organizations with no previous obligation to adhere to them. (See Figure 2.)
Relating security-related test artefacts to security related requirements in LDRA’s TBmanager tool.
For instance, J3061 discusses privacy in general and personally identifiable information (PII) in particular. This information is a valuable target for a bad actor, and its vulnerability is no less significant than the potential compromise of safety systems. In practical terms, then, an ISO 26262-like rigor is required in the defense of a whole manner of personal details that can potentially be accessed via a connected car including personal contacts, credit card and other financial information, and browser histories. It could be argued that this is an extreme example of the general case cited by J3061, which states that “…there is no direct correspondence between an ASIL (Automotive Safety Integrity Level) rating and the potential risk associated with a safety-related threat.”
Today, car manufacturers and suppliers have increasingly higher expectations for software developers to reduce the risks associated with both functional safety and security vulnerabilities. ISO 26262 requires any threats to functional safety to be adequately addressed, implicitly including those relating to security threats. However, the standard doesn’t provide explicit guidance relating to cybersecurity.
SAE J3061, launched In January 2016, helps to fill that gap. Created as a complementary guideline to other security-related standards for automotive software and organizations such as AUTOSAR, it describes a process framework for cybersecurity that an organization can tailor along with its other development processes. This systematic framework supports developers’ efforts to design and build cybersecurity into vehicle systems, as well as to monitor and respond to incidents in the field and address vulnerabilities in service and operation.
Not only does SAE J3061 bring formal development to less safety-critical domains, it also extends the scope of that development far beyond the traditional project development lifecycle. Examples include the need to establish an incident response process to address vulnerabilities that become apparent when the product is in the field, consideration for over-the-air (OTA) updates, and cybersecurity considerations related to PII when a vehicle changes ownership.
To this end, J3061 provides guidance on best development practices from a cybersecurity perspective and calls for a similar sound development process as the familiar ISO 26262. For example, hazard analyses are performed to assess risks associated with safety, whereas threat analyses identify risks associated with security. The considerations for the resulting security requirements for a system can be incorporated in the process described by ISO 26262, part 8, section 6: “Specification and management of safety requirements.”
Another parallel can be found in the use of static analysis, which is used in safety-critical system development to identify construct, errors, and faults that could directly affect primary functionality. In cybersecurity-critical system development, static code analysis is used instead to identify potential vulnerabilities in the code.
SAE J3061 can be considered complementary to ISO 26262 in that it provides guidance on best development practices from a cybersecurity perspective (threats), just as ISO 26262 provides guidance on practices to address functional safety (hazards). SAE J3061 also calls for a similar sound development process and mirrors ISO 26262’s development phases.
In fact, when applying J3061 in a development team that is already following ISO 26262, the processes are complementary enough that they lend themselves to integration at each stage of the product lifecycle—to the extent that the same test team could be deployed to fulfill both safety and cybersecurity roles. While neither document mandates the use of automated tools, their use is almost essential in all but the simplest projects. But just as the documents complement each other, the same tools can be used to support them concurrently.
This allows development team managers to breathe a sigh of relief, knowing that they can implement cybersecurity processes without significant impacts to budgets or schedules. For a more comprehensive examination of SAE J3061 implementation, download here.