Refine Your Search

Topic

Search Results

Standard

Road Vehicles - Cybersecurity Engineering

2020-02-12
CURRENT
ISO/SAE DIS 21434
A framework is defined that includes requirements for cybersecurity processes and a common language for communicating and managing cybersecurity risk. ...This document specifies requirements for cybersecurity risk management regarding engineering for concept, development, production, operation, maintenance, and decommissioning for road vehicle electrical and electronic (E/E) systems, including their components and interfaces. ...This document does not prescribe specific technology or solutions related to cybersecurity.
Standard

Cybersecurity Guidebook for Cyber-Physical Vehicle Systems

2016-01-14
CURRENT
J3061_201601
This recommended practice provides guidance on vehicle Cybersecurity and was created based off of, and expanded on from, existing practices which are being implemented or reported in industry, government and conference papers. ...Other proprietary Cybersecurity development processes and standards may have been established to support a specific manufacturer’s development processes, and may not be comprehensively represented in this document, however, information contained in this document may help refine existing in-house processes, methods, etc. ...This recommended practice establishes a set of high-level guiding principles for Cybersecurity as it relates to cyber-physical vehicle systems. This includes: Defining a complete lifecycle process framework that can be tailored and utilized within each organization’s development processes to incorporate Cybersecurity into cyber-physical vehicle systems from concept phase through production, operation, service, and decommissioning.
Standard

Cybersecurity Guidebook for Cyber-Physical Vehicle Systems

2016-02-19
WIP
J3061
This recommended practice provides guidance on vehicle Cybersecurity and was created based off of, and expanded on from, existing practices which are being implemented or reported in industry, government and conference papers. ...Other proprietary Cybersecurity development processes and standards may have been established to support a specific manufacturer’s development processes, and may not be comprehensively represented in this document, however, information contained in this document may help refine existing in-house processes, methods, etc. ...This recommended practice establishes a set of high-level guiding principles for Cybersecurity as it relates to cyber-physical vehicle systems. This includes: • Defining a complete lifecycle process framework that can be tailored and utilized within each organization’s development processes to incorporate Cybersecurity into cyber-physical vehicle systems from concept phase through production, operation, service, and decommissioning. • Providing information on some common existing tools and methods used when designing, verifying and validating cyber-physical vehicle systems. • Providing basic guiding principles on Cybersecurity for vehicle systems. • Providing the foundation for further standards development activities in vehicle Cybersecurity.
Standard

Automotive Cybersecurity Integrity Level (ACsIL)

2016-06-15
WIP
J3061-1
A Threat Analysis and Risk Assessment Method that would work with the classification scheme or from which we could map into a specific level in the cybersecurity integrity classification scheme a. This will require reviewing existing TARA methods and deciding on one or a tailored version of one Determine how to relate the ACSIL for safety-related threats to the ASIL from ISO 26262
Standard

ISO/SAE 21434 Road Vehicles - Cybersecurity Engineering

2020-03-03
WIP
ISO_SAE21434.D1
A framework is defined that includes requirements for cybersecurity processes and a common language for communicating and managing cybersecurity risk. ...This document specifies requirements for cybersecurity risk management regarding engineering for concept, development, production, operation, maintenance, and decommissioning for road vehicle electrical and electronic (E/E) systems, including their components and interfaces. ...This document does not prescribe specific technology or solutions related to cybersecurity.
Standard

Permanently or Semi-Permanently Installed Diagnostic Communication Devices, Security Guidelines

2020-03-04
CURRENT
J3005-2_202003
The scope of the document is to define the cyber-security best practices to reduce interference with normal vehicle operation, or to minimize risk as to unauthorized access of the vehicle's control, diagnostic, or data storage system; access by equipment (i.e., permanently or semi-permanently installed diagnostic communication device, also known as dongle, etc.) which is either permanently or semi-permanently connected to the vehicle's OBD diagnostic connector, either SAE J1939-13, SAE J1962, or other future protocol; or hardwired directly to the in-vehicle network.
Standard

SAE J1939 Network Security

2017-03-06
WIP
J1939-91
This document will provide recommendations to vehicle manufacturers and component suppliers in securing the SAE J1939-13 connector interface from the cybersecurity risks posed by the existence of this connector.
Standard

DATALINK SECURITY PART 1 - ACARS MESSAGE SECURITY

2007-12-10
CURRENT
ARINC823P1
The purpose of this document is to provide an industry standard for ACARS Message Security (AMS), which permits ACARS datalink messages to be exchanged between aircraft and ground systems in a secure, authenticated manner using a uniform security framework. The security framework described herein is based on open international standards that are adapted to the ACARS datalink communications environment.
Standard

Survey of practices for securing the interface through the Data Link Connector (DLC)

2017-07-05
WIP
J3146
This document has been issued to provide a reference or overview of some current practices which could be utilized for securing the vehicle’s interface with the Data Link Connector (DLC) from cybersecurity risks associated with external test equipment connections (e.g. diagnostics scan tools) or remotely connected applications (e.g. telematics devices).
Standard

GUIDANCE FOR USAGE OF DIGITAL CERTIFICATES

2018-07-11
CURRENT
ARINC842-2
This document sets forth guidance for life-cycle management of public/private (i.e., asymmetric) keys that are used to secure interactions among systems.
Standard

Service Specific Permissions and Security Guidelines for Connected Vehicle Applications

2020-02-05
CURRENT
J2945/5_202002
SAE is developing a number of standards, including the SAE J2945/x and SAE J3161/x series, that specify a set of applications using message sets from the SAE J2735 data dictionary. (“Application” is used here to mean “a collection of activities including interactions between different entities in the service of a collection of related goals and associated with a given IEEE Provider Service Identifier (PSID)”). Authenticity and integrity of the communications for these applications are ensured using digital signatures and IEEE 1609.2 digital certificates, which also indicate the permissions of the senders using Provider Service Identifiers (PSIDs) and Service Specific Permissions (SSPs). The PSID is a globally unique identifier associated with an application specification that unambiguously describes how to build interoperable instances of that application.
Standard

Hardware Protected Security for Ground Vehicles

2020-02-10
CURRENT
J3101_202002
Access mechanisms to system data and/or control is a primary use case of the hardware protected security environment (hardware protected security environment) during different uses and stages of the system. The hardware protected security environment acts as a gatekeeper for these use cases and not necessarily as the executor of the function. This section is a generalization of such use cases in an attempt to extract common requirements for the hardware protected security environment that enable it to be a gatekeeper. Examples are: Creating a new key fob Re-flashing ECU firmware Reading/exporting PII out of the ECU Using a subscription-based feature Performing some service on an ECU Transferring ownership of the vehicle Some of these examples are discussed later in this section and some have detailed sections of their own. This list is by no means comprehensive.
Standard

Electron Beam Powder Bed Fusion Process

2020-07-01
CURRENT
AMS7007
This specification establishes process controls for the repeatable production of aerospace parts by Electron Beam Powder Bed Fusion (EB-PBF). It is intended to be used for aerospace parts manufactured using additive manufacturing (AM) metal alloys, but usage is not limited to such applications.
Standard

Security Testing Methods

2016-08-26
WIP
J3061-2
This document serves as the initial framework for defining the subject. The document serves as a detailed breakdown of security testing methods related to software and hardware testing. it is to remain vendor agnostic and focus on the type of testing available at the time of release. This is not a comprehensive list and is intended to be updated on a yet to be defined timeline.
Standard

Security Testing Tools

2016-08-26
WIP
J3061-3
This document serves as an internal list of manufacturers of security related tools and their capabilities. This list is not intended as an endorsement of any manufacturer but rather a list of examples and capabilities that exist within the market.
Standard

E/E Data Link Security

1991-09-16
HISTORICAL
J2186_199109
This SAE Recommended Practice establishes a uniform practice for protecting vehicle components from "unauthorized" access through a vehicle data link connector (DLC). The document defines a security system for motor vehicle and tool manufacturers. It will provide flexibility to tailor systems to the security needs of the vehicle manufacturer. The vehicle modules addressed are those that are capable of having solid state memory contents accessed or altered through the data link connector. Improper memory content alteration could potentially damage the electronics or other vehicle modules; risk the vehicle compliance to government legislated requirements; or risk the vehicle manufacturer's security interests. This document does not imply that other security measures are not required nor possible.
Standard

Airworthiness Assurance for Airborne Electronic Hardware (AEH) Containing Commercial-off-the-shelf (COTS) Electronic Components

2018-12-19
WIP
ARP7495
This document addresses issues related to assurance that COTS electronic hardware components will perform their intended function in the AEH equipment or system in which they are installed. Those issues may impact system design, reliability assessment, quality, testing, production or support; but this document is not intended to be specific to any of those disciplines. This document is focused on the hardware issues raised in DOT/FAA/TC-16/57; it does not include issues related to software, firmware, etc. This document is intended to fit within the development process for civil aircraft and systems. This document can be used to support design and analysis activities in RTCA DO-254/EUROCAE ED-80 and RTCA DO-297/EUROCAE ED-124, as well as SAE ARP4754. This document addresses twelve (12) of the twenty-six (26) specific issues described in DOT/FAA/TC-16/57.
X