Although the model was built independently, based on experience in aircraft and railway systems. It is at the crossroads of two other security models: it can be seen as an extension of the Zero Trust model, which, built with an enterprise network in mind, does not address various levels of criticality of systems. It can be seen as a simplified, specific-purpose ISO62443 Zone & Conduit model, which, on the other hand, proposes a methodology that is independent of any context.
This document should be useful to functional and security architects alike.
One of the major issues that systems engineering faces is how to deal with systems for which the complexity is so high that requirements and constraints cannot fit into any one person’s brain. Security is no different, and dealing with complex, embedded, critical systems involves keeping tracks of thousands of features, use cases, threats and interactions between vulnerabilities.
The way to deal with such complexity is typically to build models, which provide simpler mental representations at higher levels of abstraction, allowing engineers to separate issues down to a manageable complexity. The model may not be a perfect fit to reality, but it helps to treat most cases. For example the hundreds of ways to organise network protocols were simplified down to the 7-layer OSI model. That model does not perfectly reflect the reality of Internet protocol, but it is useful to compare protocols. The Perdue model is equally over-simplified, but helps greatly in understanding the ins and outs of an industrial network.
For us, security architecture for aircraft took off, so to speak, between the design of the A380 and that of the A350. The security model that came out of those designs is documented in the ARINC 811 standard, which splits aircraft networks into three domains. Our consultancy then took us to new technical domains, in particular the railway domain, where we found much the same functional, safety and security requirements as in aircraft. There we started to formalise the common requirements, and built a model coupled with technical solutions, which is now used in other domains as a yardstick with which to measure other architectures.
While real-world architecture rarely fits directly into the model, it still proved a very useful tool for analysis and for formalising the areas of concerns of the systems under analysis: where it differs from the model, is usually where the problems lie. This document is our view of this abstract model. It starts from the security principles we follow, the functional requirements that seem to appear in most systems, then it lists the basic security functions used to build the model. Finally, we present the various elements of the model.