On December 13, 2020, notifications were sent out from the Solarwinds CEO, Kevin Thompson alerting the estimated 300,000 customers of their product, ORION, that they were just made aware of a "a highly sophisticated, manual supply chain attack on SolarWinds® Orion® Platform software builds for versions 2019.4 through 2020.2.1."
It appears, and the details are still unfolding, that the malicious code was seemingly injected into patches and/or software updates sent out to approximately 33,000 customers, of which an estimated 18,000 were running the affected versions. But Solarwinds was only alerted, some 5 days after cyber security experts FIREYE announced they suffered an intrusion from which some 300 of their tools were stolen.
The full extent of the attack and how it was carried out will have further ramifications on the Cyber Security industry for years to come. Not only did this attack infiltrate Fortune 500 based companies, but it also affected government organizations, used to protect our security, both domestically and internationally. The Department of Homeland Security and their branch of Cybersecurity and Infrastructure Security Agency (CISA) were affected.
Type of Attack Matters
Traditionally there have been a few types of main attacks that occur. Outside-to-Inside attacks (i.e. penetration testing, denial-of-service) or Inside-to-Outside attacks (i.e. social engineering, ransomware, spyware/malware). But this sort of attack was definitely an inside attack, but artfully crafted in a very unique way. I don't mean to glamorize the attack at all, but the level and sophistication of the attack is one that we haven't seen in years.
Access was granted at some level for the malicious code to be introduced into the software development life cycle (SDLC), with zero checks or balances in that development cycle, so the code could be introduced into the software releases (2019 and 2020 versions). It has all the earmarks of a social engineered attack, but so much more.
What it calls out is that every company could have potential liabilities within their software development process where malicious code could be injected into what was thought to be a secure part of the development cycle.
For years, we have put software and hardware in place to protect our perimeter. We have installed intrusion detection systems (IDS) and intrusion prevention systems (IPS) for internal threats. Paid and supported for a security industry to ensure our laptops, desktops, servers and systems were protected by the best software money could buy. But we forgot to look at what is now the most vulnerable and exposed systems in our companies. The software development process.
This attack will give rise to new technologies and protections, and I am sure, new industry standards and regulations to help bolster our defenses against such future attacks.
What can be done?
Certainly, we need much better communication channels. While the age of privacy is important, and with the strict privacy laws of California and EMEA (GDPR) as examples, we have to balance the privacy and anonymization of data with that of an effective response to cyber terrorism. When we talk about cyber attacks, more information could mean the difference between stopping a threat quickly before it has a chance to take off. Think of the multi-agencies involved with domestic terrorist threats - the breaking down of the walls between agencies is critical to stop a threat from foreign terrorists.
Handling of cyber attacks are not much different than how we respond and react to terrorist threats to our cities and people.
Better Quality Control and Reviews
While the details of this attack are still being uncovered, we do know that malicious code was introduced into the Solarwinds Orion software process. In an article from KREBSONSECURITY.COM, a user reported on twitter of an open GITHUB Repo.
If this is the method from which the malicious code was introduced to the system, then what is critical is that the quality control and testing process failed Solarwinds. In this day and age of rapid (Agile) software development and automation, we forget that there still should be strict code reviews. I am not suggesting that Solarwinds needed to perform a line-by-line review of the code for each and every patch, but using AI and machine learning, it might be necessary to run code review through software to verify the veracity and integrity of the software from patch to patch and version to version.
If we can automate the development process to create the patches, surely we can automate the code review process in a way that is efficient and looks for all the DIFFS (differences between two files) and analyzes those details for any malicious code or call-outs.
On top of that - proper patch testing in a very controlled and segregated environment with massive auditing and logging facilities to see what the software is doing might also be necessary.
What Can Be Done Now?
Stay vigilant. Analyze your current exposure points and don't take any part of your processes for granted, from development, to the quote-to-cash process, to the most minor systems in use on your network.
A good cyber security program might have uncovered this issue. It might find exposures at your company that you can mitigate. Don't be comforted by the level of your SDLC automation or sophisticated. In fact, I would say the opposite. With the level of sophistication and automation multiplied by the amount of hands touching that process, will increase the exposures and level of scrutiny required to ensure the integrity of the process.
IT cannot do it all. A good cyber-security process cannot protect everything. The statement, 'it takes a village', comes to mind. Internally, this becomes a multi-departmental process to uncover possible exposures. Tearing down department silos and exposing all the warts and ugliness of the SDLC process are critical to mitigate these sorts of issues in the future.
Technology will catch up, quickly, but until then, it will be the work of the company to ensure this sort of attack never happens again.