SolarWinds Experimenting With New Software Build System
CISO of SolarWinds now has complete autonomy to stop product releases if security concerns exist, CEO says.
March 31, 2021
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt1d8d52d6b98f48cf/64f1500a2087df0086110394/Solarwinds.jpeg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
SolarWinds is experimenting with a completely new software build process that CEO Sudhakar Ramakrishna says is designed to ensure much better security against intrusions of the sort that the company disclosed last December.
In addition, SolarWinds' CISO has been given full autonomy to stop product releases from happening purely due to time-to-market reasons. A new committee for cybersecurity has also been established at the board level, which includes the CEO and two CIOs, Ramakrishna said in comments during a virtual panel discussion this week involving security leaders from multiple organizations.
The measures are part of several changes that Ramakrishna says he has implemented since SolarWinds disclosed a breach of its systems three months ago that resulted in malware called Sunburst being distributed to some 18,000 customers worldwide. A substantially smaller number of them—including FireEye and Mimecast—were subsequently targeted for further compromise.
The intrusion involved attackers gaining access to SolarWinds' software-build environment and injecting the Trojan into automatic updates of the company's Orion network management software.
According to Ramakrishna, the company's investigation shows the attackers somehow gained access to its build environment and managed to inject code dubbed Sunspot into a single source-code file that was fetched from the file system as software was being compiled. The attackers later used Sunspot to inject the Sunburst Trojan into the Orion updates.
The attack had nothing to do with SolarWinds' source-code control systems, and neither did it result in any source code getting changed: "What simply happened was during the automated build process, the Sunspot code, which was sitting in memory quietly was watching for one file to be fetched," Ramakrishna said. The malware then essentially flipped the file and the compilation just continued. "So, you would not find source code logs; you could not go back in time and look at it," he said.
The entire process of modifying one file with malware happened in a window of a few milliseconds - and in memory - as the software was being compiled. The software was later digitally signed and sent out in automated fashion to customers of Orion.
Multiple Build Systems and Pipelines
To ensure that attackers cannot pull off a similar caper, SolarWinds is seeing if it can design its software-build systems and pipelines a bit differently.
Instead of a single build system in a single location, the company is looking at possibly running two or three parallel build systems through two or three parallel build chains. The goal is to see if SolarWinds can establish software integrity across multiple pipelines to avoid supply chain attacks of the kind it experienced a few months ago, Ramakrishna says. An attacker would have to be right three different times, identically, to be able to conduct an attack like the recent one with Orion. SolarWinds has also implemented a two-way hashing algorithm to further establish the integrity of its software.
The idea is to get to a point where code-signing certificates won't be the only way to establish software integrity. SolarWinds wants to "actually build a level of non-repudiation in the code to say, 'I underwrite and undersign what I am delivering,'" Ramakrishna said.
As part of the effort, SolarWinds is also implementing processes to ensure its CISO has more independence and authority. "We are creating an independent organization to build that level of capability and comfort," Ramakrishna said. "Having that level of independence, confidence, and aircover is supremely important. Otherwise, [security] becomes a cost line-item and they get sidelined."
SolarWinds is still in the process of trying to figure out how the attacker—believed to be a sophisticated nation-state-backed actor—managed to infiltrate the company's build environment in the first place.
At one point, incident investigators had as many as 16 different hypotheses for might have happened. They have now whittled that number down to three by a process of elimination, but have not yet been able to narrow it down any further.
Ramakrishna said that the three current theories are that the attackers either got in via a very targeted spear-phishing attack; or by exploiting an unpatched vulnerability in some third-party software at that point in time; or via a credential compromise.
He said that available evidence suggests the attacker behind the operation is very sophisticated and highly organized.
About the Author
You May Also Like
State of AI in Cybersecurity: Beyond the Hype
October 30, 2024[Virtual Event] The Essential Guide to Cloud Management
October 17, 2024Black Hat Europe - December 9-12 - Learn More
December 10, 2024SecTor - Canada's IT Security Conference Oct 22-24 - Learn More
October 22, 2024