The Ripples From SolarWinds

In the final month of one of the most unprecedented years on record, a breach was discovered in the Solar Winds supply chain that rocked the cybersecurity community deeply. The potential access points were in multiple companies and government agencies, most disturbingly the Department of Energy, which handles nuclear power plants.

To be clear, there has been no announcement that the breach in any way affected the power grid or the power plants of any sort. There has been no data available to show any impact at all.

This may have been simply an attempt by a malicious actor or group to see how far they could infiltrate the systems. It may have been in progress still, and had not done damage until it reached a certain level of infiltration. Or it may have done damage we do not know of yet. Some of the information will never be made public due to security concerns, so we may never really know the full scope of the damage.

While infiltrating major government systems is terrible, the secondary impact is in some ways equally damaging. Trust in the security of software was damaged, potentially permanently. New avenues of threat have been revealed, and those worries are valid. But there are lessons we can learn from this attack and turn into good security practices going forward.

1. Keep your eyes open. The malicious and sneaky nature of this attack made tracking and noticing it extremely difficult. Much of the information was stored in legitimate files and often actions mimicked regular system functions. As security professionals, we should always be asking “why?” when looking through the code. Why does this file need access to that one? Why should this user type have these certain permissions? Why is this abandoned gem or library still in the app?

2. Don’t put time limits on discovery. The FireEye team did a wonderful debrief on the SolarWinds attack, and the thing that struck me was that they mentioned that the process would take the time it took. There was very little talk of time frames or deadlines. The focus was instead on gathering the information, assessing the full scope of the breach, and tracing the path of infiltration. This attack was massive and unusual in the way it persisted through virtual machines and legitimate files. It was slow moving but intentional, and extremely hard to find it all. The team focus on gathering the full picture allowed the problem to be assessed and handled in a way that left a much smaller risk of dangling vulnerabilities or persistent malicious code in the system.

3. Communicate thoroughly. There were multiple teams working on different aspects of the problem, but they were all highly connected. The constant, open, and thorough communication of the teams was very evident even in the debrief video. Each team was working on a part that led to the common goal, and the focus was on accurate information rather than assigning blame.

4. Nothing is impossible. The way this attack was carried out is an avenue that is not easily exploited. Massive amounts of time and effort went into this attack, and honestly, it was impressive. (Impressively bad, but still quite impressive) The biggest takeaway I have from this hack is that we can shore up all of our known vulnerabilities and access points, but really, the only 100% secure application is the one that doesn’t exist.

Some people have viewed this attack as just one in a long series. Others mark this as the beginning in a new avenue of attack that could take years to fully understand. Sadly, we will likely never see the full picture of the SolarWinds attack due to privacy and security. But that doesn’t mean we can’t learn from the incident and improve our own processes. Bettering our own processes and practices won’t stop all attacks, but it will make us a harder target to crack.