5 cybersecurity lessons from the SolarWinds breach

1. Simulate a ransomware attack

Ransomware attacks are a tremendous concern for companies of all sizes, but few companies know exactly how easy it is to launch one in their own network. Secureworks' ransomware simulation service uses a remote device on a user segment to simulate a compromise in the network -- for example, a supply chain vulnerability such as what happened with SolarWinds. "From there, we look to see what we can access -- can we move laterally to deposit ransomware payloads? As an adversary, we see how far into the network we can go," Burchell said. The company takes note of missing patches and unsecured pathways that are vulnerable to a payload deposit. Simultaneously, Secureworks measures the ability of the business to detect and respond to the compromise. "We ask internal teams to assess themselves and share with us the things they didn't see or respond to," Burchell added, sharing that wireless guest networks are one of the most overlooked vectors of attack.

2. Test your vendors' software for vulnerabilities

While businesses might ask for third-party validation of a vendor's software to check a compliance requirement box, Seemant "Sam" Sehgal, founder and CEO of penetration testing-as-a-service platform provider BreachLock Inc., said companies themselves should take responsibility for the integrity of the software they bring onto the network. "If you, as an enterprise, aren't watching what you are introducing in terms of software code or service provider applications, you are leaving yourself vulnerable to a hack like SolarWinds," Sehgal said. Security assessments for all software and SaaS purchases should be centralized so the applications can be properly tested and validated. "If a company department located in another country uses a certain piece of software that interacts with the network, you need to know."

Automated code reviews -- even if they are supported by AI -- have their limitations because they can't always detect "unknown unknowns," according to Sehgal. For instance, the SolarWinds attack relied on a code injection that looked legitimate in the sequence code. A manual review would have investigated how the code called other machines, including who was being called and where the updates were coming from. If anomalies were detected, a reviewer would have called for reverse-engineering the software to track down the offending code. Without such human-augmented testing, "if a cyberthreat materializes, you are on the hook because you had a step missing," Sehgal said. "That step -- a hybrid approach where automated security checks are complemented by a human-led penetration test (pen test) -- could have potentially detected the vulnerability and limited the damage."

3. Don't rely on internal developers to test internally developed software

Developers should not have the final say on how secure their code is. They are not security experts, and they might be the ones who inserted malicious code, intentionally or not, according to Nabil Hannan, managing director at pen testing provider NetSPI. "To uncover a SolarWinds type of issue, you have to think differently than a developer would about what you are looking for, including who has access to your systems," he said. "How can a developer determine another developer's true intent for putting code in the system and how it will behave? He can't." Hannan recommended forming a group of trusted executives and senior managers to work with an external testing firm. When developers are done with their reviews or completed updates, the group sends it to the testers to look for malicious code and insider threats. "We examine the source code and binaries, looking at executables and comparing what is published versus what is in the source code," he said. Testers search for backdoors, time bombs, Trojan horses and signature patterns. "If there are differences, we will report back to the group in a discreet way and work with them to mitigate the issues." Hannan said having this practice and these controls in place are helpful when there is a management shakeup, a disgruntled developer leaves or a merger or acquisition is about to take place.

4. Make sure you have logs and can access them

"Customers will call and say, 'We had a breach,' and we say, 'Let us see your logs,'" said Brad Herring, vice president of business development at pen testing company Raxis. "That's when they realize they don't have logs." Herring said this happens with companies of all sizes and across all industries. Even if they have logs, Herring said they often don't keep them past 15 or 30 days, which wouldn't be adequate to do an investigation on the impact from the SolarWinds attack. "We want them to be able to share firewall logs, workstation logs, server logs, [intrusion detection/intrusion prevention system] logs … basically any logs in the enterprise that show inbound/outbound traffic." Otherwise, he said, testers can't tell that all the patches, service closures and other remediation efforts worked. "The worst is when clients say their managed service provider has the logs, only to find out they don't, and they never verified that they did. The SolarWinds attack has been an eye-opening experience for them," Herring said.

5. Require vendors to do continuous security and risk assessments of their software, not just point-in-time assessments

One of the downfalls of a checkbox approach to security is vendors can show a point-in-time assessment that reflects a strong security posture but doesn't give the whole picture. "You get an assessment at the beginning of your contract, and then there are years of nothing," said Alex Rice, founder and CTO of HackerOne, a vulnerability and bug bounty firm. "You don't even get to build a relationship with response teams at the vendor. In fact, for many companies, this was their first interaction with the SolarWinds response team." Rice believes businesses should demand ongoing security and risk assessments from their vendors when they sign their initial and subsequent contracts. Many software vendors are hesitant to release that information because "there are few incentives to be transparent," Rice said. "The more you disclose, the more at risk a deal can be." HackerOne offers its clients information about every security incident it has had or discovered since 2012. "When other vendors are saying, 'We don't have any vulnerabilities or downtime,' we give them even our near-misses," he said. "It makes our customers informed." Rice finds it unacceptable that there isn't full transparency about what happened with SolarWinds and urges the industry to make changes to address this need going forward. "Customers need to know where the problem exists in their other vendors and how they plan to prevent it from happening again," he said. "People are trying to respond to the hack but are doing so blindly." Having the leverage of a requirement for continuous security assessments would encourage more information to come forth.

As these lessons learned are implemented, businesses should try to reduce the stigma surrounding the use of external security services, such as code reviews, pen testing and vulnerability scans, according to Raxis' Herring. "Business leaders need to help us break down the stigma that these firms are out to get IT and developer teams. We are not about a pass/fail or getting anyone in trouble. We are here to shine a light, help find vulnerabilities and mitigate them and reduce an organization's risk," he said.