Skip to content

More platforms equals less security


09:00 Tuesday, 14 September 2021

UK Cyber Security Council

The introduction of a new IT system induces mixed emotions in security specialists.

New technology brings an opportunity we don’t often get: to design the security properly, from the ground up. We can work with the implementers to design security into the system, engineer the Single Sign-On to integrate smoothly with the central directory service, ensure that it’s able to provide audit logs and feeds of user data so that operational security can be monitored.

Nine times out of ten, though, introducing a new system brings a major downside: you’re increasing the amount of technology and the number of systems. That remaining one time out of ten - when you’re introducing a system that will replace something you already have - then there’s a tremendous chance of a net improvement, security wise. In fact, if you can’t get a net increase in security when replacing a legacy system with something new, something has almost certainly gone awry. But most of the time you’re adding to the estate - putting in something new without taking out something old - and hence are increasing the potential security headache.

One of the more minor downsides, in fact, is the increment to the system estate: because you have the opportunity to be part of the implementation, you should be able to implement something with a high degree of confidence about its security. So the addition to the overall “raw” security quotient should be modest.

The issue is not so much with the numeric addition of a system but with the fact that technology is seldom stand-alone. Although any new system is unlikely to interact directly with everything you already have, it is highly likely to link to several systems and processes. The number of interactions between systems grows geometrically as the number of systems grows, which brings with it not just the task of securing those interactions but also the challenge of monitoring the interactions to ensure they remain correct and secure.

Think back to the “CIA” (Confidentiality, Integrity, Availability) triumvirate. Confidentiality is what we mean by the “raw” security quotient mentioned earlier, and is the least worrying element of the three. Integrity is very much at risk when new systems are brought in, because the interactions mentioned a few sentences ago have to be correct: if they’re not, the integrity of the company’s overall data collection is under threat. As far as availability is concerned, this can suffer as a knock-on of an integrity issue, but even in its most fundamental form, the basic fact is that if there are more devices and systems this means that there are more things that can go wrong, and anything interacting with a system that fails is at risk of having an availability problem too.

So, what can we do about it? Can we, the security team, just say no? Would the organisation ever listen to the security team telling them that the new system they are proposing to implement is a bridge too far, and takes them the wrong side of the security line? No, probably not: unless we can point out a fundamental flaw that makes it legally, or perhaps morally/ethically unwise to adopt a new system, the security team is unlikely to have power of veto.

But it is realistic to go back to security first principles and take a risk-based approach. We should take a calm, measures approach and address the situation in the way we know best: identify, quantify and assess the risks that the new technology presents, communicate them to senior management, and invite them to consider your results in the context of the organisation’s risk appetite. By all means propose alternative approaches to mitigation, and similarly think laterally - maybe even point out that the additional risk of the new system could be more than offset by decommissioning some other, legacy, less secure application. It makes sense to look holistically in this way because it would be inherently wrong to think in isolation about the risk of what’s proposed: what you, the executive and the board care about is the company-wide security picture, not a collection of distinct localised, application- or system-specific risks.

“The worst enemy of security is complexity”, wrote global security guru Bruce Schneier in November 1991. Twenty years on, he’s still right.