Resilience

An application can run without problems for years. Employees rely on it, processes are built around it and there seems to be no reason to change anything. Until suddenly a security risk arises, without a single line of the application having been changed.

We saw that again this week. The PHP Security Team warned about two critical vulnerabilities in PHP, a programming language on which websites and business-critical applications run worldwide.

It shows how dependent software is on the technology it is built on. Programming languages, frameworks, servers and external components are constantly changing. A vulnerability in one component can have consequences for the entire system.

But what do you do when such a situation arises? Who needs to be called in, which systems are involved and which measures are needed to limit the risks?

Recently we heard a colleague in the field talking about ICOS: In Case Of Shit. A simple principle that got us thinking. In the meantime we have set this up at Wabber in our own system, with worked-out scenarios and for each customer the right contact information, parties involved and agreements. That way we have everything at hand immediately when something goes wrong.

Because during an incident you do not want to first have to figure out who to call or which supplier is involved. You want to be able to quickly assess what is going on and act in a targeted way.

The question is not only whether your software works well today, but also whether you will know tomorrow what is needed to keep it secure.