When I started my career almost 30 years ago, IT Security just arrived in the public from a former academic topic. With the broad adoption of the Internet, the science of cryptography entered a new age, “making the Internet secure” with standards like SSL/TLS and IPsec.  We still use them in a not-so-different way since then. Many fundamental security and trust concepts were developed in academia these days, for instance multilateral security, which I put in context to the Zero Trust paradigm recently.

You might have heard about the “CIA goals” when it comes to develop and implement security protocols: Confidentiality, Integrity, and Authenticity. CIA still is the basic concept of “security engineering”. All of these goals can be achieved by well-researched cryptographic building blocks: encrypt (AES), cryptographic checksums (HMAC-SHA-3) and signatures (EC-DSA) – leaving the Post Quantum debate aside for the moment. And, believe me, it’s still a high art to get this right!

However, my teachers always insisted: “ah, and don’t forget availability as a fourth security goal!”. Or, closely related, resilience. That’s interesting. I met many security apologists in my further life claiming, “the most secure system is one you do not connect to the network”. And even further, in a sense of desperation facing increasing complexity: “it’s even better to not switch them on at all”.

Wow, that’s secure! But the opposite of useful, isn’t it?

My learning from my teacher’s appeal is: Security Engineering has the responsibility to provide secure and available solutions. But that’s hard sometimes, as goals are often diverging or even are in contradiction. Examples? Digital certificates have an expiration date. Checking validity and expiration of a certificate by time, CRL, OCSP or whatsoever, finally ends up in a decision to deny a connection in TLS or IKE, for instance. Mostly for good reasons (like manipulated certificates). But sometimes for management failure, due to a missing update of the certificate. Do you want to build in an insecure fallback to prevent such situations? Another – related – example: security certification. Bugfixes must come quickly, certification takes months or years. Install the bugfix OR keep a certified state? That’s a situation we should not stick with, but better work on the processes.

A related concept, closer to the availability goal, is “fault tolerance”. Basically, that’s the answer to Murphy’s Law. Things can break, things will break, and there should be fallbacks, may be less functional, less capable, but still something. Space missions are a good example, where a lot of engineering effort is put into fault tolerance, as costs are huge to setup a new mission when something went wrong.

Oh, yes, that’s the common denominator of all these concepts: of course, the invest in safety, fault tolerance – and security – depends on what value you want to protect. This is quite easy to calculate for a space mission. However, sometimes we forget to take strategic values into account. Supply chain problems, single-source dependencies etc. are result of underrated long-term risks (and costs), as we had (and have) to learn these days. But I don’t want to deep-dive into (digital) Sovereignty here – which is probably another blog post topic.

Instead, let’s have a closer look into the resiliency of our critical infrastructures. Infrastructure starts on the physical layer: cables and fibers, pipes (when it comes to liquids) and so on. Sometimes we forget that fact in the virtualization and “software-defined” hype: there always has to be some hardware underneath! Recent attacks on cables of the German railway system sparked a discussion about the security (sic!) of this critical infrastructure. Why could the attackers cut this communication ring so easily? Because it is well known that the cables are going along the rails. And – until now – German railways is happy to own its cables, because they feel secure, independent… Are they?

It seems to be a common (mis)understanding to own cables is more secure than transmitting sensitive data (for instance controlling railway signals and track switches) over third party infrastructure. It’s not – from a security point of view, there are protocols like IPsec VPN or Layer 2 encryption making such connections as secure and private as own cables. However, from a resilience perspective, one could argue it is better to rely on the availability of my own cables. It could be. But therefore, you need a lot more – in terms of cables, but also in terms of the layers above. Especially you must run resilient protocols and application layers on top of these many cables (and radio / satellite connections). Here is the good news: there are very robust protocols and orchestration stacks available today.

Let’s travel back into the 1960’s. The time of the cold war and nuclear threat. And the first networking experiments between computers. The time when the Internet was born, and packet-switched networks. The very first goal of the Internet Protocol design was resiliency (a fact we still struggle with 50 years later, as CIA goals were not that important – so, don’t forget them either). Routing protocols providing a distributed knowledge about reachability, link quality and availability are the core of the Internet. Despite local outages and political motivated centralization for surveillance purposes, today we can consider the Internet as one of the most robust infrastructures.

So, just buy your DSL access? Not really… back on the physics, of course it’s pointless to run a super-resilient protocol over one physical layer if that’s the only way to your critical application. However, it’s also not that clever to run old protocols and applications over your own (and single) cables that cannot deal with an outage.

When it comes to security, we often see VPNs re-establishing the CIA goals on top of a public packet-switched network. A very secure and proven technology for that is IPsec. But with the design of IPsec, this often ends up in static “virtual cable” configurations often putting the resiliency of the underlying infrastructure in question. At least it leads to a very static overlay network. Many years ago, we decided to overcome these statics by engineering a new automated VPN overlay configuration called SOLID. It utilizes a peer-to-peer protocol to distribute knowledge about reachability in a ring structure (which itself is an IPsec VPN). We were led by the goal of a decentralized knowledge, and it makes a super-secure IPsec VPN staying super-secure, but very easy to configure and yet still robust to run.

Interestingly, current networking hypes like SDN are often built on centralized knowledge. Formerly distributed routing protocols now become dependent on centralized “controllers” and policy enforcement. Instead, we plead for fully decentralized knowledge and enforcement, whereas it’s valid to centrally manage overarching policies. Our research in secure SDN / SDWAN concepts provide evidence that this is possible.

As a short summary here: mixed physical infrastructures combined with the robustness of the Internet Protocols, and a well-engineered security layer can provide a very resilient AND secure networking layer today. Own cables with ancient protocols cannot.

But the networking layer is only one part of the equation. So, let’s have a look at the next floor of the protocol stack – the applications. Big monolithic application designs led to the beloved (or feared) 9x’s. 99,999… datacenter availability, geo-redundancy, big emergency power supplies and so on. All this somehow jeopardizes the decentralized approach of a packet-switched network, at least. But nowadays cloud technology is making its career, and with it the advent of micro services. That will probably become a paradigm change like the step towards the Internet design in the networking space in the 60’s: it allows to build intrinsically resilient applications without having these 99er datacenters, as it doesn’t need a designated physical cable (I mean: computer) anymore. Applications can be transparently relocated if hardware fails. The “routing infrastructure” is provided by a microservice orchestration layer like Kubernetes.

Of course, this needs new paradigms in application design. I like the terms of “eventually-consistent databases”, “immutable VMs” and “chaos engineering”. Resiliency is not about all or nothing, but always to have some meaningful functionality left. Get rid of the endless 9’s in a single location, but distribute your connectivity, data and workload. The advent of edge clouds therefore is promising, but we are still very dependent on centralized datacenters today, and even more, on an oligopoly of cloud providers. Ok, I promised to postpone the sovereignty topic for today. But this is also a matter of resiliency.

Of course, such a concept of distributed workload needs new paradigms in security engineering, too. Everything is based on virtualized infrastructures (storage, network, compute) – the cloud, so to say. And this infrastructure needs to provide security concepts to relocate microservices securely. I don’t want to find my k8s container run on a computer in a non-trustworthy country, so I didn’t want to get my IP packets with sensitive data routed through non-trustworthy telco networks in cleartext. VPNs are there, but we also need something like a “Virtual Private Cloud”, provided by cryptographic means, decentralized and resilient. We are not yet there; we are even only at the beginning. However, the ingrediencies are growing with secure virtualization capabilities, dynamic and scalable VPNs like our SOLID, and things like Confidential Computing.

We invite you on the journey there, with our extraordinary background in security engineering and the learning from my teachers always in mind: resiliency is always part of the security goals.

PS: While we often do that vice versa (mostly very satisfied), German railways is explicitly invited to travel with us on this journey.