System Security and System Safety Engineering: Differences and Similarities and a System Security Engineering Process Based on the ISO 26262 Process Framework
Bibliographic record
Abstract
Today's vehicles contain a number of safety-critical systems designed to help improve overall vehicle safety. Such systems may control vital vehicle functions such as steering, braking and/or propulsion independently of the driver. In today's vehicles, much emphasis has been placed on helping ensure that these safety-critical vehicle systems operate as intended. Applying rigorous system safety engineering principles in developing these safety-critical automotive systems helps ensure that they operate as desired and expected. Less emphasis has been placed to-date on helping ensure cybersecurity of cyber-physical automotive systems. However, this is changing as both the world and the automotive industry become more aware of the potential ramifications of cyber-attacks on vehicles. As with system safety, applying a rigorous system security engineering process to the development of cyber-physical automotive systems is beneficial and will help reduce the likelihood of successful attacks on vehicles. System security and system safety interact with one another and cannot be considered in isolation. However, there are also differences between system security and system safety that require unique engineering activities to be performed to address these unique aspects. This paper describes some of the differences and similarities between system security and system safety, between safety-critical systems and security-critical systems, and between system safety and system security engineering, and presents a system security engineering process for applying to cyber-physical automotive systems that is based on the ISO 26262 process framework.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.030 | 0.021 |
| Meta-epidemiology (narrow) | 0.002 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.007 | 0.007 |
| Science and technology studies | 0.003 | 0.016 |
| Scholarly communication | 0.014 | 0.014 |
| Open science | 0.002 | 0.006 |
| Research integrity | 0.005 | 0.012 |
| Insufficient payload (model declined to judge) | 0.003 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".