There’s no question that a career as a top security leader is rewarding and something to aspire to. But before you consider taking that career path, there are some lessons to be learned from a recent case that shows just how tough a job it can be. You’ve gotten the education, paid your dues and you’re ready to tackle the role of CSO or CISO, to make the big decisions and determine how security will be a key part of your firm and what it does.
Before you start down this road, or even if you are continuing down this road, there are some lessons that can be learned from the trial of the Securities and Exchange Commission (SEC) versus SolarWinds and its CISO Timothy Brown. It’s an important case and one that demonstrates potential severe repercussions for CISOs and has even caused some to reconsider the role. How would you have handled the situation if you were in charge?
The SEC has accused Brown of misleading investors by not disclosing “known risks” and not accurately representing the company’s cybersecurity measures during and before the 2020 Sunburst cyberattack that affected thousands of customers in government agencies and companies globally. “SolarWinds violated reporting and internal controls provisions of the Exchange Act; and Brown aided and abetted the company’s violations,” the SEC said in a press release.
Risk management and disclosure are key complaints by the SEC
The claimed failures, including not abiding by the statements that the company made on its website regarding their patterns and practices for developing their software as well as password policies internal to the company. The SEC complains in its filings that the company did not disclose cybersecurity risks independently from other risks, given SolarWinds’ role and industry (it sells a network and applications monitoring platform called Orion), nor pay extra risk attention to targeted attacks and the disclosure needs surrounding them.
The SEC found internal emails in which the CISO indicated that the company was not abiding by its public security development lifecycle statement. When communication indicated that improvement was needed internally, there was no communication in the SEC filing that these actions were being worked on. When others in the network security team were indicating deficiencies in network access and VPN protocols, it appears that actions were not appropriately taken.
There were emails, internal messages, and text messages documenting internal knowledge that customers were at risk using the software as well as increasing evidence that attackers knew of the situation as well. However, during this time no disclosures were made to the SEC or even to customers at risk.
Like many attacks these days, it appears that the attackers first came into the network via remote access and a VPN vulnerability. The attackers inserted the malicious software into SolarWinds products which in turn was delivered to over 18,000 customers worldwide.
When early attacks were noted, impacted firms asked whether other attacks had been seen in the wild by other customers, and the CISO communicated that he had not seen examples. He then went on to admit privately that he had lied to the customer. When an 8-K statement was finally filed acknowledging the security issue, the SEC indicated that “it was materially misleading in several respects, including its failure to disclose that the vulnerability at issue had been actively exploited against SolarWinds’ customers multiple times over at least a six-month period.”
Public claims on a website need to reflect internal procedures
When you make security statements on a website, whether you are bound by SEC regulations or a small company assuring your client base, make sure the claims you make in public match up with what you are doing in the company. SolarWinds claimed that it followed “moderate level framework NIST Special Publication 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations (NIST 800-53).”
In reality, in January of 2021 an internal assessment was made, and it found that 60% of the controls were completely unmet. When your primary product is security, then you can’t skimp on cybersecurity disclosures. Cybersecurity risks and practices are important for nearly any firm, but to a firm like this, which provides cybersecurity, this is a key to the business itself. Especially for a firm that develops security software, ensuring that it’s checked for vulnerabilities and web application testing should be mandatory.
Passwords and password handling are key concerns for any business, but a security firm should pay closer attention. It’s vital that if you have a stated policy you follow that policy. If your internal needs and practices are such that a mandated password change and complexity is not attainable, then you need to change your processes to work with the needs without decreasing your security posture.
These days the mandate of changing passwords is beginning to be put aside as a best practice and instead looking for ways to increase your security with the use of alternative authentication methodologies such as authentication applications and other two-factor authentication technologies. Vendors should code their applications to encourage such better practices of software handling as well as encourage the use internally.
Password handling needs to be done with appropriate rigor
Software and hardware devices should not have any default passwords built into the platform. These types of settings expose these devices to attack using relatively easy techniques are far too common and should never occur.
When passwords are used in applications they should be handled in an appropriate manner and encrypted where needed. Databases should never have default passwords, nor should they be stored in an insecure method. In addition, any passwords used in a software development process should never be stored in software repositories.
In the case of SolarWinds, a public GitHub repro included credentials belonging to SolarWinds. Password handling in software development can be fraught with bad practices. I have personally seen FTP usernames and passwords sent in emails to consultants and developers working on a joint project. Too often the demand for getting a project done in a timely manner will lead individuals into making insecure decisions.
Learn from the mistakes that others are making
The SEC also indicated that SolarWinds did not limit administrative access to those who needed access. Too often in developer networks administrative rights are used too widely and not limited. Internal staff expressed concerns that user access would lead to losses of organizational assets and personal data. Furthermore, it appears that logging of this access did not occur. It’s key in any sized network or organization that logging resources are allocated appropriately.
While this has been deemed to be an attack launched by a nation-state, the SEC indicated that the exposure to vulnerability could have been remedied through basic steps. They make the claim that the failure to comply with basic security practices also does not excuse hiding these failures from investors. In addition, the company knew that there were security issues surrounding their managed service products.
The company indicated that the risks surrounding their MSP products were significant. Furthermore, Brown and management accepted the risks of legacy software were so great that it could not be fixed in a timely manner.
The bottom line is not to be a SolarWinds — look at your own failings and ensure that you are honest with yourself, your customers, and more importantly your investors. If your internal meetings indicate that you need to immediately take action, do so. Being in a leadership position means that the buck has to stop with you. What sort of CISO are you? What would you have done differently if you were in charge of the situation?