3 minute read

An automobile story

Firmamentum’s legal council asked me not to mention the date this story took place, who the people involved were, or the make/model of the car…

Once upon a time, a major car manufacturer was working on a new car. Their cars were expensive and prone to be stolen, so security was at the forefront of their mind. Their cars had a reputation of being especially safe, so the safety features would have to be better than the ones they had previously. Continuous improvements, right?

Some clever marketing person suggested that they hire a former car thief to test the security of their car. What a good idea. They found one, and all he requested was the manual for the car. Because a good show is always welcome, the demonstration of the attempted break in would be live. They were so sure. Can you see where this is going yet?

Car thief

Come the day, the thief is introduced. The car is revealed. Oohs and Ahs abound. All is going so well. Then, the thief asks for a hammer. A simple humble hammer. No worries whatsoever, the glass is reinforced, there’s been testing, no problem. The thief circles the car, looks deep in thoughts, and slams the hammer into the front collision sensor of the car.

BOOM goes the air bag.

As a safety feature, all the doors open. The thief smile, gets in the care, and hot wires it.

Whoops…

How does this map to software?

There is a Unix philosophy that states: that a tool should do one and only one job. ls lists files; cd changes directories; find finds specific items; cat concatenates files; etc… The power comes from combinations of those different tools.

In operations, separation of concerns is also a must. One and only one service should run on a machine (or VM, or pod or container image, …) at a time. Partly, this is driven by security as well. It’s best not to have your customer database on the same machine that host your email and web servers.

Why?

Well, if a threat actor breaks into your web server, they have access to your full database. If they are two separate services, then there is a better chance of the threat actor having only restricted access to the database.

But, it’s not just a security concern.

Imaging you have your web server and your email server on the same machine:

  • When an OS upgrade goes wrong, both your web server and your email server go down.
  • If you get a DDOS attack on your web server, your email goes down too.
  • If you get a massive influx of spam emails, your web server goes down too.
  • If you want to have a second web server… Do you clone the machine and have two email ones?
  • A web admin has the same access than an email admin. They can interfere with each other’s work.

network

Monitoring of resources is much easier if you have different machines doing different things. Upgrades are easier. Administration is easier. It’s a win-win.

However…

And this is a big one. In a car, you cannot have one safe and another one secure. This does not work. Neither does it work when you are programming giant underwater robots: if the robot’s legs are powered by 400 bar hydraulics, they will not notice a human body in the way. This is where communication comes in! You need to be clear where the dangers are, and what mitigations can be in place. Optimisation is done based on different, often contradictory goals.

In mathematics optimisation theory, we call those bilevel optimisation. For example, pick the best place to maximise a function while minimising a second one. The first function could be a tool charge, while the second is the travellers desire to move to an alternative route. Or safety vs security of the car…

Conclusion

How would you address the car’s safety vs security concern?

Maybe a piece of code that detects whether there is a person in the car, or blocks the engine, or have some good remote tracking, or what? What new problems does this cause?

This is the type of complexity that we’re looking for when we build software.

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

How about getting in touch to see how we can help you?

Updated: