Supply chain attacks demonstrate the need for multiple controls
If you’ve been paying attention to security news over the last few days, you’ve no doubt heard about the SolarWinds security compromise that has affected several US government agencies, the cybersecurity company FireEye, and possibly thousands of other private companies. I don’t want to give a detailed analysis of the event here, as there are better, more insightful posts about it elsewhere, but here’s a quick summary:
SolarWinds is the distributor of Orion, a network management program designed for large, enterprise-level networks. Essentially, a yet-to-be-identified (“officially,” at least — most analysts are fairly confident it was a Russian-state backed hacking group) and extremely sophisticated malicious actor managed to compromise the software supply chain for SolarWinds and corrupted the update process — leading to several thousand organizations downloading a trojanized update file for Orion that installed backdoors on multiple systems. If that sounds bad, that’s because it is — SolarWinds supports “over 425 of the US Fortune 500, all top ten US telecom companies…all five branches of the military” and several federal US departments and agencies (Gatlan, para 3). According to official sources, nearly 18,000 individual companies may currently be compromised due to this hack.
Software supply chain attacks of this type are fairly uncommon — I can’t remember reading about another one this big before — but they can be extremely consequential. Obviously, if a legitimate company is distributing malware to its customers, that’s bad for business, but this can also be hard to detect, particularly if the process is obscured. In the SolarWinds case, trojans were embedded in updates that were compiled by a trusted source, so it’s easy to see why the attack was undetected for months.
This latest security episode reminded me of a risk mitigation strategy that came up when I was studying for the CompTIA Security+ exam a few months ago — vendor diversity. Vendor diversity isn’t necessarily discussed a whole lot when covering risk management, but this could certainly be considered an example of having “all your eggs in one basket” (so-to-speak). Smaller vendor diversity may give the impression that a company can become an expert at a particular platform, and, indeed, as an owner of multiple Apple products, I understand the appeal of easily incorporating new devices into an existing system. However, by limiting your technological solutions to a very small pool of vendors, you may actually introduce more risk to your organization. For one, you could have single point of failure, as we saw in the example with SolarWinds — the single compromise of Orion led to system-wide compromises in company networks. Additionally, keeping your number of vendors relatively low also introduces risk through a few other avenues: possible lack of innovation or available technologies, higher equipment and service costs, and supply chain issues (again seen in the SolarWinds example).
Diversifying vendor solutions is an example of risk management but it is also an example of the security practice of “defense in depth.” Defense in depth is the concept of layering multiple security strategies, so that, if any one point fails, there are still multiple security strategies or controls in place to slow down or stop an attacker regardless. With a network, defense in depth is demonstrated by deploying firewalls, isolating VLANS, using NIDS and NIPS systems, and more. In the same way, we reduce risk by employing multiple strategies to contribute to an overall posture of reduced or mitigated risk. Defense in depth is a fundamental security strategy necessary in every setup regardless of size or complexity.
In the case of SolarWinds, a single solution for managing a corporate network is probably still preferable. It’s likely not cost-effective to have multiple network managers and it would definitely be a headache for any engineer who has to maintain such a setup. Because of this, other types of risk compensation are necessary to account for the introduction of this potential point of failure. For instance, some antivirus programs exempt particular software libraries from scanning for malicious activity (indeed, some software makers actually request this), but, obviously, this introduces its own set of risks, particularly if that software is ever compromised. Additionally, security engineers will want to keep an eye on their DNS logs to make sure network traffic is legitimate and not requesting problematic IP addresses. Again, in the case of the Orion compromise, if your logs go back far enough, FireEye has released Indicators of Compromise (IoCs) that can be found in DNS logs to confirm that your network has been compromised by this particular attack.
Fundamentally, good security will never be one, comprehensive solution. Any individual control’s effectiveness could be reduced or altogether removed, and, if that happens, you will absolutely want other strategies in place. Information security isn’t just a single wall — it should be fortress.
