Due to new technologies for connectivity, automotive systems shift from a closed to an open system approach.Therefore, automotive systems have a rising demand for security, letting security be an upcoming field in research and practice.Also, the newly published process standard ISO/SAE 21434 demands adjustments in the development process to address cybersecurity.The unique characteristics of automotive systems leave many approaches from other system types inapplicable.This work concentrates on the risk treatment step in the cybersecurity development process.Due to the vast amount of differing terminology, we see the need to define a flexible taxonomy adaptable to several system types and used in systems with normative references.We use this taxonomy to develop a heuristic approach for risk treatment based on a distinct terminology for security requirements.The presented method is extendable to include several trade-off points.

Formal reasoning about the correctness of safetycritical system properties is crucial since such systems may impact their environment when malfunctioning.The Rail Safe Transport Application (RaSTA) Protocol is a protocol for systems used in railway applications such as signaling.It claims to provide highly available and timely communication based on the application's demands.We investigate timeliness, i.e., the property that application data do not become obsolete.We analyze the protocol's specification and provide assumptions necessary to resolve imprecisions.Under the specified error model, we find that the deadlines proposed bound until messages are considered timely is too restrictive, disabling RaSTA's mechanisms to recover from lost messages in time.We formalize the specification of timeliness to provide a counterexample for the proposed bound and create an improved bound that does not lead to violated deadlines under the same assumptions and error model.

Future automotive software needs to deal with an increasing level of dynamicity, reasoned by the wish for connected driving, software updates, and dynamic feature activation. Such functionalities cannot be properly realized with today's classic AUTOSAR development approach, since it relies on the static configuration of all software units at build time.