Cybersecurity Control
A cybersecurity control is a technical or operational measure through which an item achieves its cybersecurity goals. The examples in ISO/SAE 21434 range from a secure communication channel to a separate microcontroller with a hardware trust anchor for the key store.
First the what, then the how
The methods of the Threat Analysis and Risk Assessment (TARA) do not speak of controls; their risk treatment only decides whether a risk is reduced. If it is, a cybersecurity goal follows. The goal says what must be protected, but not how.
Work on the how already starts in the concept phase. For the cybersecurity concept, the standard requires you to describe the technical and operational controls that achieve the goals, and how they interact. The description has to take into account the cybersecurity claims and the dependencies between the item’s functions. It can state, for example, whether a control is meant to prevent a compromise or to detect it. Together with the cybersecurity requirements, it makes up the cybersecurity concept.
So controls don’t only belong in development. If you only read the TARA clauses of the standard, that is easy to miss.
Development makes controls concrete
In product development, controls are selected and specified. The cybersecurity specifications are explicitly based on the controls selected for implementation, and these may come from trusted catalogues. Hardware counts too: whether a component has enough processing power and memory for a control can feed into the specification. The standard describes this work as iterative: it continues until no control needs further refinement.
That is not the end of it. At the end, the cybersecurity assessment checks whether the implemented controls are appropriate and effective.
Controls in the analysis
A control can also sit in the environment. For its headlamp example, Annex H of the standard assumes that the gateway has strong controls including a firewall, developed to CAL 4. Here the analysis relies on a control it doesn’t specify itself.
Whether a control lowers a risk only shows in the risk value. It has to act on the attack paths that drive the risk. And whether it helps depends on the risk matrix: in the example matrix of Annex H, moderate impact gets the same value for low and for medium feasibility. A control that pushes a path from medium to low changes nothing there.
That is why itemis SECURE attaches a control to the threats it mitigates. The attacker has to overcome it on their path, and the engine recalculates feasibility and risk. Our article on threat scenarios and attack paths explains how attack paths are rated.