Gânduri Eclectice – Eclectic Thoughts

Today starts with reading about a couple of very old fashioned exploits from earlier in the week. So very old-fashioned that one is left thinking “Really?” Hard coded default credentials. Are we back in the 1990s again suddenly? A short, maybe slightly rant-y item here today.

Maybe it is time to revisit Defence in Depth? As in, understand it and actually DO it?

Stupid is as stupid does

Whilst the flaws here are right up there on the stupid scale, such things are still going to happen from time to time. It’s human nature; we do silly things, we make mistakes. Review processes should catch these, but they are not always good or even in place.

Single Failure Should Not Cause Serious Compromise

Rule of thumb: at least two different things should have to be badly broken at the same time before any catastrophic failure is possible

— Me, frequently since 1991

This is the essence of defence in depth. Layers of security should protect you from catastrophic results even when something goes wrong. Your VMs should not be randomly accessible via SSH using passwords from the Internet. Your Solarwinds infrastructure should similarly be protected from direct external access. Yes, you may have internal bad actors, but cutting out the external threat is a useful start. To be fair, the Kubernetes one requires access at build-time to exploit, but it is an unnecessarily slack and insecure approach that has been taken – using a fixed password for the duration of the build process rather than a random one.

Assurance

Whilst performing assurance on systems, I all too often discover single failure points which would, by themselves, be catastropic. We talk about software engineering and systems engineering but actual engineers building actual structures would be horrified at the fragility of these systems. We need to think more like actual engineers, in my opinion.

Conclusions

Things go wrong with controls. So for each control, consider

• threats that it is intended to defend against
• how it might fail, so that you can make that less likely
• what compensatory controls (extant or possible) will save you from disaster if it does fail
• adding such compensatory controls which are possible but absent

Few (practical & effective) controls are without limitations or failure modes. A little additional thought up-front can save you a tonne of cleaning up later.