In December 2020 it became public knowledge that popular network management software vendor, SolarWinds, had been breached by an entity likely to be a nation state threat actor. But that is where the damage only begins. SolarWinds is (was?) a supplier to many organisations around the world including government and critical infrastructure in the US which the threat actor appears to have been mostly (but not only) interested in.
It is fairly well known that the average time to detect a cyber breach is 280 days (almost a year!) and that is held true in the SolarWinds breach if you consider that SolarWinds itself was breached back as early as September 2019. The nation state threat actor appears to have waited patiently until February 2020 before taking advantage of its access (and US distractions) to add a malicious component to the SolarWinds software update service.
The malicious component was identified by security firm FireEye whilst undertaking a forensic evaluation of its environment in response to the theft of its own security testing tools. Whether they're testing or hacking tools depends on your point of view! Tech and security companies have given the hack a wide variety of names starting with UNC2452 by FireEye, as well as SUNBURST, SUNSPOT, Raindrop, TEARDROP, Dark Halo and Solorigate (by Microsoft).
Applying the MITRE ATT&CK framework
There has been extensive media coverage of the SolarWinds breach and one of the best comes from the team at MITRE which highlights UNC2452-Related Techniques based on its popular ATT&CK framework. The SolarWinds breach investigation has lead to updates in v8.2. The best thing about the ATT&CK framework is the Mitigations and Detection information available for each technique that can help incident response and threat hunting teams.
Check out the techniques relevant to the SolarWinds breach in this diagram from MITRE (and refer to the ATT&CK framework itself for more details on each):
SolarWinds + Coffee + ISO 27001
Inspired by this diagram from MITRE, I found time last weekend during a rain storm and caffeine high to think about other standards like ISO 27001 and how relevant they are in mitigating these types of sophisticated attacks. Some tech folk will believe threat intelligence, hunting and patches are the only way. And whilst certainly useful, it is also necessary to think about how we can address root causes and break the cycle.
So, I decided it would be a useful exercise to prepare something similar for ISO 27001.
(Open the image link and zoom in for best results)
Let's consider the relevant ISO 27001 controls:
Password management system (access control) - Despite SolarWinds offering solutions for managing passwords as well as best practice guidance, it definitely did not set "quality passwords" when it used "SolarWinds123" for remote access to its software update service. Lesson to learn -> Ensure quality passwords and make sure your vendors do similarly.
Inventory of assets (asset management) - It is always helpful to know what software you depend on. Anyone who subscribes to vulnerability lists knows the challenge of determining relevance to your environment, so an inventory or register of your software assets is essential. Further to this, an inventory of your significant information and classifications will help guide priorities.
Operations security - It is an oversimplification to say that standard controls against malware would have mitigated the SolarWinds attack. Given the attacks use of novel techniques and code the lesson learnt is you (and you suppliers) must go beyond signature based antivirus to application whitelisting and have thorough event logging and analysis in place so you can detect threats and explore historical flows when responding.
Key management (cryptography) - Security professionals, and almost every computer user through awareness raising, knows the value of multifactor authentication (MFA). However, poor access controls and key management can mean that signing keys can be stolen and MFA can be bypassed.
Lesson to learn -> Infrastructure and keys must be protected and keys must be changed if at all suspected of compromise.
Segregation in networks (communications security) - It is still surprising (even shocking) to see poorly managed firewall rules and network access controls. Long gone are the days (if in fact they ever existed) where you could filter inbound and not outbound connections. Attacks like these nation state attacks and more common phishing attacks succeed from time to time. When they do, you want to be watching for exfiltration (even to same country destinations).
Security requirements analysis & specification (Information system acquisition, development & maintenance) - It is important to document the security requirements you have when you acquire systems (like the SolarWinds Orion Platform). Software evaluations processes like the Common Criteria can be useful to ensure base products are effective. But exemptions are usually made to deviate from the trusted baseline to apply updates.
This is good when they contain necessary security patches but not so good when they include malware. Code control, 'dual' (at least!) review and authorisation processes along with automated code analysis should help.
Supplier relationships - Perhaps the most important lesson to be learnt from the SolarWinds breach (other than the one around quality passwords!!) is that whilst we may have great policies (and do most of what we say we will do) our suppliers are often doing less. They don't share the same risks profiles and appetite.
We must define our requirements for suppliers (drawing from the other pointers in this blog), ask the question and make sure they're being met.
Information security incident management - Defined responsibilities and procedures for information security incidents will help you deal with the largely inevitable; you will experience a(nother) incident. The lesson learnt is how important it is to be engaged with your vendors/partners operating in concert to challenge each other, apply strong(er) security, detect attacks, prevent breaches and respond quickly when they do occur.
Security is a constant process of vigilance and improvement and should never been seen as an end goal.
Compliance - An independent review of information security including a review of technical compliance can help make sure you're doing as good as you can, this includes internal audits, supplier audits, configuration reviews and penetration testing. If you're not reviewing compliance, then you have no assurance things are the way you need them to be to manage your risk.
If you want to know how these ISO 27001 controls may relate to those in other frameworks like the NIST Cyber Security Framework or others, you can always get that from Hailey.