Patch me if you can: Can Elon Musk be a role model for IT security?

Patch me if you can: Can Elon Musk be a role model for IT security?

Famous people are often controversial. Some of them are both godly worshiped and envied and also laughed at, whether rightly or not.

He has a weak point for risks and writing about cyber: In his main job as a security researcher at HiSolutions AG, David Fuhr rages on and rages on in this column about current incidents and general truths of information security. In addition to new articles, articles already printed in the iX appear here – always with a tongue-in-cheek update on the current security situation.

The billionaire jack-of-all-trades Elon Musk is known for a lot – and hated for a lot. Even if he may not understand much about hydrology in the Brandenburg region, he is definitely one thing: a first-class engineer. But what makes his space company SpaceX so different? And what happens if we apply his patent recipe for design processes – whether for rockets or for electric cars – to security? Time for a thought experiment.

Musk sees the following five rules as the core of his engineering success. As we shall see, the decisive factor here is the sequence.

First, make the request less idiotic. Second, delete as many steps in the process as possible. Third, simplify and optimize. Fourth, reduce lead time. Fifth, automate. Let’s look at that in detail.

We often make the mistake of taking requirements as absolute. We try to optimally implement the “how” according to some standards, while we do not question the “what”.

Example: Does the standard want to force regular password changes without cause? Actually, it’s about protection against brute force. The protocol should be “encrypted”? What is really needed is integrity protection; an HMAC (hash-based message authentication code) does this much faster and easier.

According to Musk, requests are especially dangerous when they come from intelligent people. Because then we may not question them enough.

The next cardinal error is to start optimizing at this point. Donald Knuth already knew that premature optimization is the root of all evil. So first of all, mercilessly brush it away, otherwise you will never get a secure system to take off. Before we install a web application firewall, we first consider whether a web application is needed at all. And the most secure password is one that you don’t even need.

Only then can we optimize – but only by simplifying. More complexity is not an improvement! Allowing the choice between AES 256 and a dozen other symmetrical encryption methods only creates room for attack surface and implementation errors.

Let’s go

Now – and really only now! – may, no, we have to pace. The point is to shorten the lead time in order to be able to learn from more cycles. A UPS or other redundancy that is never tested is worthless – it’s better to pull the plug twice a year. And if the attackers come by so seldom that we cannot learn from their tricks, we have to hire attackers (pentest, red teaming) or otherwise practice attacks (simulation games).

The problem with the space shuttle was that there was no room for improvement due to the constantly manned flights: every small change to the system could have triggered a catastrophe, so for safety reasons known errors and legacy issues were retained instead of cleared up. For security, we rather need systems like the Starship from SpaceX, which due to the lack of a crew is sometimes allowed to blow up (small joke …).

The principle is also described as chaos engineering for IT, but has so far been used more homoeopathically. One could also include honeypots: systems that are attacked as often as possible so that we can learn from them. Or containers with “self-healing powers”.

“Sure, Security Automation!” Is what you want to say now – finally! And by doing so, I am shouting at the obvious thing: If we have followed the previous four steps and have designed a potentially secure system, we now have to automate production. How much is – in terms of efficiency and security! – won if all VMs are always created from the same two or three carefully hardened images. And how much error-prone work can a skilful CI / CD or build pipeline do for me, so that I don’t have to turn on the linter for a code analysis every time (or forget to do so).

Another tip from engineer Musk is at least worth considering: only if everyone is a “chief engineer” will everyone understand the overall system and can judge what good optimizations are – or bad ones, such as the web browsers that have tried to cross- Removing site scripting code from web pages and tearing even bigger loopholes in the process.

One thing is clear: if our IT systems want to safely fly to Mars, we have to experiment a little more.

This column was published in iX 09/2021 and has been updated for the online edition.

More from iX magazine

More from iX magazine

More from iX magazine

More from iX magazine


(ur)

Article Source