One of the security principles by which we[1] live[2] is that security is only as strong as the weakest link in a chain. That link is variously identified as:
- your employees
- external threat actors
- all humans
- lack of training
- cryptography
- logging
- anti-virus
- auditing capabilities
- the development lifecycle
- waterfall methodology
- passwords
- any other authentication mechanisms
- electrical wiring
- hurricanes
- earthquakes
- and pestilence.
Actually, I don’t think I’ve ever seen the last one mentioned, but it’s only a matter of time. However, very rarely does anybody bother to identify exactly what the chain is that it is being broken by the weakest link splintering into a thousand pieces.
There are a number of candidates that spring to mind:
- your application flow. This is rather an old-fashioned way of thinking of applications: that a program is started, goes through a set of actions, and then terminates, but to think more broadly about it, any action which causes an application to behave in unexpected or unintended ways is a possible security flow, whether that is a monolithic application, a set of microservices or an app on mobile device.
- your software stack. Depending on how you think about your stack, there are likely to be at least 5, maybe a dozen or maybe even scores of layers in your software stack (for an example with just a few simple layers, see Announcing Enarx). However you think about it, you need to trust all of those layers to do what who expect them to do. If one of them is compromised, malicious, or just poorly implemented or maintained, then you have a security issue.
- your hardware stack. There was a time, barely five years ago, when most people (excepting us[1], of course), assumed that hardware did what we thought it was supposed to do, all of the time. In fact, we should all have known better, given the Clipper Chip and the Pentium bug (to name just to famous examples), but with Spectre, Meltdown and a growing realisation that hardware isn’t as trustworthy as was previously thought, everybody needs to decide exactly what security they can trust in which components.
- your operational processes. You can have the best software and hardware in the world, but if you don’t maintain it and operate it properly, it’s going to be full of holes. Failing to invest in operations, monitoring, logging, auditing and the rest leaves you wide open.
- your supply chain. There’s a growing understanding in the industry that our software and hardware supply chains are possible points of failure[3]. Whether your vendor is entirely proprietary (in which case their security is largely opaque) or open source (in which case you’ve got a chance to be able to see what’s going on), errors or maliciousness in the supply chain can scupper any hopes you had of security for your deployment.
- your software and hardware lifecycle. Developing software? Patching it? Upgrading hardware (or software)? Unit testing? Unit testingg? We all know that a failure to manage the lifecycle of our environment can lead to security problems.
The point I’m trying to make above is that there’s no single chain. Your environment is n-dimensional – your trust must be, too. If you don’t think about all of these contexts – and there will be more beyond the half-dozen that I’ve just noted – then you can’t have a good chance of managing security in your environment. I honestly don’t think that there’s any single weakest link in the chain, because there are always already multiple chains in play: our job is to think about as many of them as possible, and then manage an mitigate the risks associated with each.
1 – the mythical “IT security community”.
2 – you’re right: “which we live by” would sound much more natural.
3 – and a growing industry to try to provide fixes.
Alice, Eve and Bob - a security blog 