Prince Igor was a highly loved and respected sovereign by his subjects. Over decades, he has been able to unify his princedom through fights, wars, alliances and diplomacy and eventually achieved peace and prosperity for his people. His subjects were extremely grateful for that. But, as someone once said, “You don’t get to 500 million friends without making a few enemies”. Jealousy notably increased among his family and allies, whereas anger grew among his enemies. Mediocre and arrogant people, who usually have a strong bias to overestimate their skills, do not appreciate success and popularity, especially when it is obtained through knowledge, reason, care and patience.
Prince Igor, being wise and smart, knew that. He also knew how fragile a system is where everything hangs on one person only. Should he disappear, everything he constructed over the years would crumble rather quickly. And he still had so much to achieve to reach his political vision! Over the years, Prince Igor created comprehensive and strong lines of defense around his person (not himself but what he represented): heavily guarded and controlled castles, trained and armed escorts, network of trusted advisors, controlled paths, armored vehicles, even a taster to ensure his food was not poisoned.
Poisoning. Here was the best point of entry to bring death to the Prince. A rational offender would never try to attack him directly. He would fall dead before trying to touch him, even remotely with an arrow. So, the other solution was to poison the Prince. For that, the attacker would need to analyze the supply chain that leads the food from the fields to Prince’s mouth. Before the taster would eat it would be riskier but could however be achieved in small quantities and on a long-term basis, but both the taster and the Prince would become sick at the same time, with the same symptoms, which would look suspicious. Not everyone is patient, and life is short – the attacker might die before the Prince is poisoned to death. So, after the taster ate it but before the Prince would have it as a meal would be more effective, but the assassin would need to introduce the poison right in time, with a very small timeframe for action and should be part of the close circle of the Prince. The whole point of poisoning was to discretely leverage the chain of trust to avoid suspicion. Only a trusted party would be able to perform such poisoning.
* * *
Do you think your company runs a highly secure IT infrastructure and has a high maturity level when managing cybersecurity risk? Sure, might be. You have secured everything possible that depends on you. But consider this: because the purpose of networking is precisely to communicate with outsiders, there is a high likeliness that your systems interact with clients or suppliers. And that some of them have access to your infrastructure. And that they are not as risk averse as you are re. cybersecurity risk (spoiler: they simply do not care).
What happened recently to SolarWinds’ clients through the malware nicknamed Sunspot (and by the way already happened almost exactly with the NotPetya malware in June 2017, or differently to Target in 2013) is precisely that through a technique called supply chain attack. SolarWinds is a company that develops software for businesses to help manage their networks, systems, and IT infrastructure. This attack is in fact an extremely clever, efficient and effective modus operandi to hit a large number of various targets across the world. I must confess that I am amazed by the sophistication level of the attackers – and we do not know all details yet.
On a regular basis, software vendors issue updates or patches. Updates deal will rolling out new functionalities or new additions to a software, whereas patches deal with removing security vulnerabilities that have been found in the software’s code, whether internally or reported from outside via, for instance, bug bounty programs. Especially if you are a relatively reputable vendor, your customers will apply updates or patches you just released because they trust you. Think a s a customer: would you systematically put into question what Microsoft sends you? And if you do, do you have the capacity to do this with the releases from each and every software that your IT infrastructure runs on, especially if you run hundreds of such of them? So, based on trust, IT departments usually deploy updates and patches to the software they run with closed eyes. And that is the flaw.
Long story short, in our case an organization hacked Orion, one of the products developed and sold by SolarWinds. Or rather, they hacked the server used to build and assemble Orion’s components (the code of the software) and installed a malware inside the next release of Orion. Once the release was distributed to SolarWinds’ clients, they installed the malware along with the update – unnoticed to them.
So, let us have a closer look at how a supply chain attack looks like and what the best practices to avoid it are. In fact, such incident can occur beyond the boundaries of software development and distribution.
If your company develops and distributes software, one of the best practices of course is that the developers test the software on a replicated but mock and isolated infrastructure to observe its behavior before distributing it to your customers. If the behavior deviates from the expected one, then something is suspicious. Other best practices include of course first and foremost account and password management, especially accounts with privileges, besides all standard organizational and technical measures. This is always the weakest link in the security chain.
In fact, the main best practice would be to have someone in charge of cybersecurity. According to a New York Times report, SolarWinds did not have a CISO (Chief Information Security Officer), and so did not Target which was hacked in 2013 – too bad. A CISO would have probably advised SolarWinds on best practices re. DevSecOps, which stands for Development, Security and Operations, i.e. embedding application and infrastructure security from the very beginning of Software Development Lifecycle (SDLC). As an example, developers can rely on the popular STRIDE model.
Be aware of what you sell to your customers – would you be willing to bring your newest iPhone to the Apple Store or your newest car to the car dealer every month to have some components repaired? Interestingly, this is exactly what happens in the IT industry: software vendors sell unstable and unsecure software, and nobody gives a damn about it. However, I bet this is likely to change in the coming years. Regulators might come into action.
On the opposite side, for customers, one of the best practices lies in a sound change and configuration management process. Basically, all changes made in the IT environment should be evaluated, assessed and tested by a change advisory board that includes security professionals, before they are implemented in a production environment. Tests should occur in an isolated replicated network (called sandbox) that imitates the main production network but without touching the production servers. Similar to the software vendor, it will help the customer evaluate the final impact on security, interoperability with other components and/or functionalities. If software behavior is suspicious in the sandbox’s environment, something must be wrong.
Third-party risk is also linked to supply chain attack. As I wrote above, many third parties usually have access to your IT infrastructure, mainly for maintenance purposes, often to industrial control systems (ICS), and are not as risk aware as you are. An unsecure, permanent connection to your IT infrastructure is a very serious security hole in the security chain, because if your supplier gets attacked, attack spreads de facto to you. Or the target is you, but as your external envelope is secure, attackers will circumvent it through your suppliers. In 2013, Target’s infrastructure was breached through its HVAC maintenance supplier.
Besides all usual protection measures, you should focus on following points to mitigate this risk:
- Before selecting a supplier, your organization must ensure they comply with appropriate cybersecurity standards – you might request risk assessments, audits. An evaluation by cybersecurity professionals is key.
- Assume they will be breached, so your company must set up plans to mitigate this – prevention and reaction.
- Ensure your contracts include specific clauses in case your supplier gets breached, and this has an impact on your organization.
- Require that the supplier contracts a cyber insurance.
- Limit internal user’s ability to install unapproved software – this is called Shadow IT, so you can control and reduce your company’s attack surface.
- Set up Intrusion Detection Systems or Intrusion Protection Systems (IDS/IPS) to detect anomalies in your network, or more advanced solutions like Security Monitoring through Security information and event management (SIEM) that works like cameras in a building, a street or a road to monitor the traffic and detect unusual events.
This kind of risk must be considered extremely seriously, not only by private companies, but also by governments. Let us suppose that criminals are able to take control of industrial control systems used to produce, say, drugs, and that they are able to even slightly change the composition of the drugs. You can understand the magnitude of a health disaster this could result in. And as I was writing these lines came out this news about poisoning a water plant in Florida, so this scenario does not look completely impossible. Interestingly, I already mentioned this type of modus operandi at a conference several years ago, in front of an audience reacting with rather incredulity and mockery – I will come back to this topic (the critical infrastructure, not my amusement) in a further article.
* * *
Once again, the conclusion is: have properly educated staff that operates your IT and ensure you have sound processes behind. Security has its costs but think about insecurity. So far, we have no idea about the financial impact of Sunburst et alii. However, we know that NotPetya’s financial impact amounted more than USD 10 BN, including several hundreds of millions of dollars for Maersk, FedEx or Merck, and a significant impact on Ukraine’s GDP – the economy lost about 0.5 % of GDP in revenue.