Browse Topic: Cybersecurity

Items (241)
There is a shift in the industry driving avionics manufactures to provide more interactive connectivity than they have had to in the past. The increasing threat of cyber security attacks in our communication systems is an increasing problem in our society and the avionics industry cannot ignore the fact that the threats are real and they must protect the systems from these attacks. Another element driving these concerns is the implementation of the FAA's NextGen or EASA's SESAR technologies which will require avionics vendors to replace their proprietary, relatively isolated embedded computer systems with information systems that interoperate and share data throughout FAA's/EASA's operations. In order to make the National Airspace (NAS) operate in the most efficient way all aircraft and ground systems will need to share information. The FAA and EASA have released standards to address these systems. This paper is only going to address aspects of security from a software perspective; more specifically, what an operating system and its environment should provide as a foundation for the security requirements. It is important to note that a generic solution to any security problem does not exist. Providing a complete security solution is the result of going through and addressing the airworthiness security process (AWSP).
Gilliland, Gary
Attacking vehicles with ransomware: Watch the horizon2022-01-04413/29/2022
Ransomware use is rampant throughout most industries. With the number of successful ransomware attacks through the industrial economy, this feels like a tsunami of attacks. These attacks seemingly originate from anywhere with an internet connection. There are vast numbers of bad actors creating these attacks, all focused on your systems. With the large number of attacks, it is granted there have been many breaches. While there have been a large number of successful attacks, each attack’s objectives have varied. These have historically been to generate revenue in the form of fees for the decrypt key or a promise not to publish exfiltrated data. The landscape has become saturated with ransomware attacks on consumers and the enterprise. There has been extensive training for staff in an effort to mitigate these issues. The next potential targets are vehicles and ground systems. These, as targets, have not been evaluated via a full risk assessment to the recommended extent. While not widely exploited, this has the distinct potential to be a significant issue. With the criticality of these systems for the troops along with the DoD, the risk for nation-state attacks cannot be dismissed or ignored. The impact of a coordinated attack would be significant. As the vehicles increase their connectivity and level of autonomy, the risks continue to grow. The compromised ground vehicle systems may lead to the vehicles inoperable, the supply chain stopping to the soldiers in the field, and distribution systems (goods and soldiers) ceasing. The paper will analyze ransomware threats, creation, pivots from present attacks, and attack methodologies.
Parker, Charles
This SAE Recommended Practice provides common data output formats and definitions for a variety of data elements that may be useful for analyzing the performance of automated driving system (ADS) during an event that meets the trigger threshold criteria specified in this document. The document is intended to govern data element definitions, to provide a minimum data element set, and to specify a common ADS data logger record format as applicable for motor vehicle applications. Automated driving systems (ADSs) perform the complete dynamic driving task (DDT) while engaged. In the absence of a human “driver,” the ADS itself could be the only witness of a collision event. As such, a definition of the ADS data recording is necessary in order to standardize information available to the accident reconstructionist. For this purpose, the data elements defined herein supplement the SAE J1698-1 defined EDR in order to facilitate the determination of the background and events leading up to a collision in an ADS-operated vehicle. The data elements defined in this document are unique to Level 3, 4, or 5 ADS features, as defined by SAE J3016, and provide additional background of the events leading up to a crash or crash-like event. The data from sensors such as camera(s), LiDAR(s) etc. will provide information in the absence of a human driver. The data included in the ADS data logger is expected to be used in conjunction with the SAE J1698 event data recorder (EDR) record and traditional accident reconstruction analysis. The EDR and ADS data logger will capture information leading up to the triggered event, at a minimum. There are no facts to support that recording data for greater than 5 seconds pre-event would change the outcome of any crash analysis. Thus, the recommended recording duration for a data logger is 5 seconds pre-event, same as an EDR. Due to the potential for sensor and/or communication failure during a crash event, the recommendation is that data should be collected post-crash for impact and rollover sensors for up to 250 ms. ADS technology is still being developed and is not yet commercially deployed. Therefore, this SAE Recommended Practice is intended as a guide toward standard practice and is subject to change to keep pace with experience and technical advances.
Event Data Recorder Committee
The security of connected health technology is often assumed to exist when it does not, or considered to be prohibitively expensive or complex, or, worst of all, relegated to an afterthought. This is dangerous thinking, especially as the industry increasingly moves to a smartphone-based command-and-control model for these safety-critical applications.
Selftrust - A Practical Approach for Trust Establishment2020-01-07204/14/2020
In recent years, with increase in external connectivity (V2X, telematics, mobile projection, BYOD) the automobile is becoming a target of cyberattacks and intrusions. Any such intrusion reduces customer trust in connected cars and negatively impacts brand image (like the recent Jeep Cherokee hack). To protect against intrusion, several mechanisms are available. These range from a simple secure CAN to a specialized symbiote defense software. A few systems (e.g. V2X) implement detection of an intrusion (defined as a misbehaving entity). However, most of the mechanisms require a system-wide change which adds to the cost and negatively impacts the performance. In this paper, we are proposing a practical and scalable approach to intrusion detection. Some benefits of our approach include use of existing security mechanisms such as TrustZone® and watermarking with little or no impact on cost and performance. In addition, our approach is scalable and does not require any system-wide changes. To detect intrusions, we propose a combination of TrustZone® secure space approach along with a mechanism of static and dynamic watermarks. The current scope of research is restricted to architectures which provide a secure space to execute software. The research is an enhancement over the current TrustZone® implementation for device control post intrusion. In conclusion, the proposed approach is a simple and scalable mechanism for detection and control of intrusion.
Abhyankar, Ranjit VinayakA, Sreenath
Challenges in Integrating Cybersecurity into Existing Development Processes2020-01-01444/14/2020
For an established development process and a team accustomed to this process, adding cybersecurity features to the product initially means inconvenience and reduced productivity without perceivable benefits. Adapting development processes to take cybersecurity into account introduces challenges not present in engineering divisions so far. Strategies designed to deal with these challenges differ in the way in which added duties are assigned and cybersecurity topics are integrated into the already existing process steps. Cybersecurity requirements often clash with existing system requirements or established development methods, leading to low acceptance among developers, and introducing the need to have clear policies on how friction between cybersecurity and other fields is handled. A cybersecurity development approach is frequently perceived as introducing impediments, that bear the risk of cybersecurity measures receiving a lower priority to reduce inconvenience. Moreover, this leads to frustration among cybersecurity developers when their proposals are not accepted, and they feel their work is not appreciated. On the other hand, putting too much emphasis on cybersecurity leads to feature creep and makes the development unnecessarily complicated without producing appropriate results. It seems natural to orientate oneself by how safety topics are handled in the development process and adjust this to accommodate cybersecurity. It is, however, not clear in which way these added responsibilities should be assigned, as conflicts of interest occur when a single person must additionally take cybersecurity goals into account, which might be clashing with other project goals this person is responsible for. Ideally, cybersecurity aspects are considered and integrated into development processes not only to fulfill customer and legal requirements, but also to enable developers of functionalities not directly related to cybersecurity to produce better and more robust results as shortcuts are no longer easily possible.
Lenhart, PatricArndt, Paulvon Wedel, JanaBeul, ChristianWeldert, Jan
Secure Vehicular Communication Using Blockchain Technology2020-01-07224/14/2020
The cars we drive are rapidly transforming. Connected vehicles in the context of the Advanced Driver Assistance System or Autonomous Vehicles are about to change the way we drive cars. Connected Vehicles are futuristic vehicles that can interact with other vehicles for passing on information such as, mapping and localization, information about road traffic and driving behaviour. However, such vehicles, particularly the autonomous ones, are prone to a variety of attacks including cyber-attacks. These malicious attacks can intrude a vehicle that not only endangers the vehicles safety, but also the life of passengers and the nearby environment. Thus, identifying and eliminating these attacks for providing a secure communication environment is of great need. Also, all the existing methods for vehicular communication rely on a centralized server which itself invite massive cyber-security threats. These threats and challenges can be addressed by using the Blockchain (BC) technology, where each transaction is logged in a decentralized immutable BC ledger. In this work, we show how BC can facilitate communication between connected vehicles to send and receive information while assuring the security of all the vehicles participating in the BC network. First, we developed an application for the blockchain based less-complex Proof-of-Work consensus method that allows the vehicles to transfer information in a secured manner. Second, we demonstrate the working of the application using raspberry pi board that act as vehicles mounted with sensors and two computers that act as blockchain network. Finally, we discuss the advantages and disadvantages of blockchain based vehicular communication and the integration of the blockchain with VANET as well.
M, Vidya KrishnanKoduri, RajeshNandyala, SivaprasadManalikandy, Mithun
This recommended practice provides common data output formats and definitions for a variety of data elements that may be useful for analyzing the performance of automated driving system (ADS) during an event that meets the trigger threshold criteria specified in this document. The document is intended to govern data element definitions, to provide a minimum data element set, and to specify a common ADS data logger record format as applicable for motor vehicle applications. The data elements defined in this document are unique to Levels 3, 4, or 5 ADS features, as defined by SAE J3016, and provide additional background of the events leading up to a crash or crash-like event. The data from sensors such as camera(s), LiDAR(s) etc. will provide information in the absence of a human driver. The data included in the ADS data logger is expected to be used in conjunction with the SAE J1698 EDR record and traditional accident reconstruction analysis. The event data recorder (EDR) and ADS data logger will capture information leading up to the triggered event, at a minimum. ADS technology is still being developed and is not yet commercially deployed. Therefore, this SAE Recommended Practice is intended as a guide toward standard practice and is subject to change to keep pace with experience and technical advances.
Event Data Recorder Committee
Service Specific Permissions and Security Guidelines for Connected Vehicle ApplicationsJ2945/5_202002 (Current)2/5/2020
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. If the application features multiple activities such that different activities have different security impacts, correspond to different roles, or require different capabilities, then the application specifier should define an SSP data structure such that the contents of the SSP in a given certificate indicate which activities the certificate holder is entitled to carry out. This document establishes a security systems engineering process that can be used by future application specifiers to (1) determine which fields and activities should be subject to SSP constraints, and (2) specify a syntax and semantics for the SSPs for that application. It also addresses the development of SSPs for scenarios not addressed in the original application specification; for example, arising from regional extensions, changes in application functionality, or future expansions of the base SAE J2735 standard.
V2X Security Technical Committee
Trust-Based Control and Scheduling for UGV Platoon under Cyber Attacks2019-01-10774/2/2019
Unmanned ground vehicles (UGVs) may encounter difficulties accommodating environmental uncertainties and system degradations during harsh conditions. However, human experience and onboard intelligence can may help mitigate such cases. Unfortunately, human operators have cognition limits when directly supervising multiple UGVs. Ideally, an automated decision aid can be designed that empowers the human operator to supervise the UGVs. In this paper, we consider a connected UGV platoon under cyber attacks that may disrupt safety and degrade performance. An observer-based resilient control strategy is designed to mitigate the effects of vehicle-to-vehicle (V2V) cyber attacks. In addition, each UGV generates both internal and external evaluations based on the platoons performance metrics. A cloud-based trust-based information management system collects these evaluations to detect abnormal UGV platoon behaviors. To deal with inaccurate information due to a V2C cyber attack, a RoboTrust algorithm is designed to analyze vehicle trustworthiness and eliminate information with low credit. Finally, a human operator scheduling algorithm is proposed when the number of abnormal UGVs exceeds the limit of what human operators can handle concurrently. Representative simulation results demonstrate that the proposed automated decision aid can effectively guide human operators when working with platoons under cyber attacks. The platoon survivability has been improved by the proposed algorithm when compared to those that operate without this system.
Li, FangjianMikulski, DariuszWagner, John R.Wang, Yue
Risk Analysis of Blockchain Application for Aerospace Records Management2019-01-13443/19/2019
Blockchain as a technology has been successfully deployed in the financial industry. As the technology continues to mature, there are opportunities to use this to solve operational challenges in Aerospace. One of the common use cases is replacing paper records as a proof of compliance with a blockchain enabled distributed ledger. Commonly available open source blockchain frameworks have security ingrained in the components. However, replacing paper records with a blockchain based distributed ledger will require investigation of potential risks involved in the end to end usage of this technology for records management. The objective of this paper is to elucidate potential risks in an aviation record management workflow environment enabled by blockchain and suggest requirements to mitigate the risks. In addition requirements for Blockchain based systems will be proposed, which will guarantee minimum functional requirements like Protection of confidential information Integrity of the information in a record Safeguards against unauthorized access The potential gaps are understood using an illustrative end to end blockchain based process along with their conceptual high level intermediate steps. For example: Authenticated trusted digital identities of the participants whose transactions are recorded in distributed ledgers Trusted source which distributes these identities and has a mechanism to update, revoke and safely secure these identities Trusted methods to ensure detection if the digital identities are compromised Trusted method to demonstrate controlled authorization process for digital identities as per access control rules Trusted methods to demonstrate the generation of accounting logs
Kar, SatyanarayanKasimsetty, VinayBarlow, SusanRao, Sujay
Experiences of Civil Certification of Multi-Core Processing Systems in Commercial and Military Avionics, Integration Activities, and Analysis2019-01-13823/19/2019
Avionics systems are currently undergoing a transition from single core processor architectures to multi-core processor architectures. This transition enables significant advantages in reduction in size, weight, power (SWaP) and cost. However, avionics hardware and software certification policies and guidance are evolving as research and experience is gained with multi-core processor architectures. The unique challenges of using multi-core processors in certified avionics will be discussed. The requirements for a virtualization platform supporting multiple real-time operating system (RTOS) partitions on a multi-core processor used in safety-critical avionics systems are defined, including the ability to support multiple design assurance levels (DAL) on multiple cores, fault isolation and containment, static configuration as per ARINC 653, role-based development as per DO-297, and robust partitioning to reduce cost of incremental certification. The paper will present a collaborative approach undertaken by a leading avionics system supplier and a leading safety-critical commercial-off-the-shelf (COTS) RTOS supplier in the development of a multi-core real-time system with DO-178C DAL A software and DO-254 DAL A hardware safety certification on an FAA Program of Record (PoR). The approach taken to comply with FAA CAST-32A objectives will be presented. Particular focus is provided for integration activities and program specific analysis performed by the IMA application developer and integrator to guarantee determinism in the deployed system. Using the approach defined under the PoR, the application developer performs activities including foot-printing under worst-case execution time (WCET) loads and application of numerical methods to predict interference effects. The IMA integrator uses this data to define a performance restricted environment (PRE) and uses WCET verification in the PRE. Tools, analysis methods, and sample results will be presented. The method to capture results is discussed. Finally the paper includes lessons learned during the program.
Tiedeman, Harold GlennParkinson, Paul
Items per page:
1 – 50 of 241