adimas - Fotolia
SolarWinds: Lessons learned for network management, monitoring
In this roundup of networking blogs, experts reveal the critical lessons learned from the SolarWinds hack in regard to network management and monitoring capabilities.
The SolarWinds breach left behind a trail of increasing cybersecurity concerns, but that isn't the only area IT teams should focus on as a result of the attack.
Since its discovery in early December 2020, the SolarWinds attack has stirred the IT world, as organizations scramble to discover if they've been hacked and move to improve their security policies as much as possible. Networking professionals, however, would benefit from taking an enhanced look at network management and monitoring best practices in their organizations, as this is also a critical area to ensure business networks and their resources are protected.
Three networking experts explored different lessons learned from SolarWinds on their respective blogs, diving into how to shrink attack surfaces, overlooked management and monitoring practices, and how something seemingly harmless could lead to trouble.
Even the best isn't perfect
Many pundits refer to vendor offerings that allegedly lead in any category as best of breed, and organizations often cherry-pick these highly regarded tools from different vendors -- one for security, one for network management and so on. Widespread use of this practice in network development led to a significantly larger attack surface for SolarWinds than it may have had otherwise, according to Steve Garson, president of SD-WAN Experts.
Many organizations and government agencies chose the SolarWinds Orion network management platform because it was highly regarded. Yet, because these organizations require what is widely viewed as the best, they adopted additional tools from other vendors, which are also supposedly the best. This monumentally increased the attack surface of the SolarWinds breach, as these tools from numerous other vendors became part of organizations' attack surfaces, Garson wrote in an SD-WAN Experts blog post.
So, the first lesson learned from the SolarWinds breach is IT teams should minimize their organizations' potential attack surface as much as possible. To start, IT teams can ask about their vendors' security policies to ensure vendors learned from the SolarWinds vulnerability and improved their policies and operations. Teams can also check on their in-house and third-party security policies and enhance patch management practices.
None of this is to say SolarWinds is not as great a company as many assumed it was prior to the breach; the main point is that not even the presumed best is safe, according to Garson.
"It's probably impossible for my clients, or any enterprise, to prevent 100 percent of all future attacks," Garson wrote. "SolarWinds is an excellent company. FireEye gets paid to protect companies against the very attacks that struck its infrastructure. If those two can be hacked, so can your organization."
Read more of Garson's advice and thoughts on how Secure Access Service Edge could help.
SolarWinds' lessons learned: Nothing can be 100% secure
While the SolarWinds hack was a breach in security, network management and monitoring flaws also contributed to the attack's size and scale. But, as IT teams determine what happened in these scenarios, management and monitoring are often overlooked, according to Tom Nolle, president of CIMI Corp.
Tom NollePresident, CIMI Corp.
Virtualization plays a role in modern network management and monitoring issues, Nolle noted, which include the following:
- If IT teams extend virtual network functions management to hosted resources for convenience, they can increase an organization's attack surface and potentially expose those resources.
- Network monitoring tools inherently provide authorized access to the network and its resources and can have backdoors -- of which a bad actor could take advantage.
In addition, when IT teams do something like add new management and monitoring layers on top of older layers, they can create more ways for bad actors to infiltrate systems and expand an organization's attack surface. This is because older layers are more likely to be forgotten, to be monitored less closely and to be less secure. And, while security professionals typically attempt to secure attack surfaces, this strategy still doesn't recognize that bad actors aren't likely to take a direct path into the network, Nolle wrote.
"Do you want a comforting solution to all of this, a tool or practice that will make you feel safe again? It's not here, nor in my view is it even possible," Nolle wrote. "There is no one answer. ... The only answer is to take every possible precaution to defend, and every possible action to audit against attempts to do something."
Learn more about Nolle's analysis of the less obvious lessons learned from SolarWinds.
Keep the backdoor locked for good
While SolarWinds has made recent headlines, it's not the only company struggling with potential backdoor vulnerabilities and network management issues. Zyxel, a network equipment provider, is also dealing with a backdoor account that threatens to exploit flaws in the provider's network infrastructure and thereby endanger customer devices, according to Tom Hollingsworth, a network professional and organizer at Tech Field Day.
Zyxel's backdoor issues can reveal lessons learned relevant to SolarWinds, too. In the early days of the internet, vendors often didn't document older features, which acted as surprise Easter eggs for users in the know. Hollingsworth cited a bear in an early Microsoft software system that users could find with a certain keystroke-and-click combination. However, if someone can figure out how to develop sweet Easter eggs, then they can also figure out how to develop poisonous ones, as well as backdoors.
That said, backdoors and software Easter eggs cannot exist anymore, Hollingsworth wrote. IT teams and vendors must document all features and code within a system so they can monitor the network and tell what code is supposed to exist within the system. If it isn't possible to document everything, IT teams must remove the backdoors or be transparent about a particular service's backdoor so users are aware of the risk.
"[I]f you create a key for a lock that should only ever be opened under special circumstances you have still created a weakness that can be unlocked," Hollingsworth wrote.
Explore more of Hollingworth's thoughts on backdoors and system documentation.