How to avoid malware

The SUNBURST malware, likely of Russian origin, was a remarkable and devastating breach of cybersecurity.  The data gathered will likely advantage the hackers and their government for years to come. If printed and stacked, the data gathered would be taller than the Washington Monument, per cyberconflict professor Thomas Rid.  

Homeland Security Adviser Thomas Bossert's op-ed in the New York Times is terrifying.  In it, he states, "the magnitude of this ongoing attack is hard to overstate...it will take years to know for certain which networks the Russians control and which ones they just occupy."  Below is a sample of the U.S. government that was infiltrated:

• Department of Agriculture
• Department of Commerce
• Department of Defense
• Department of Energy
• Department of Health and Human Services
• Department of Homeland Security
• Department of State
• Department of the Treasury

The types of commands that could be executed on the system include:

• Registry operations (read, write, and delete registry keys/entries)
• File operations (read, write, and delete files)
• Run/stop processes
• Reboot the system

How did the hack happen?

This was not a direct attack of these systems. Instead, the hackers infiltrated a trusted vendor (SolarWinds; NYSE: SWI), and that vendor's software was installed on systems. This is what is known as a Supply Chain Attack — the vulnerability is upstream of the eventual hacked software you install on your systems.    

While we can only speculate, some investigators have found that SolarWinds developers had made four mistakes: 1) they accidentally saved the FTP credentials for downloads.solarwinds.com to a git repository, 2) the password for those credentials was the weak 'solarwinds123', 3) that git repository was accidentally left public on GitHub, and 4) the FTP server allowed write access to the account with the weak password. I've noticed when I bring this up, most developers roll their eyes and mock. However, in my experience, this is an extraordinarily common mistake. Of all the security audits I've done for our DevSecOps offering, the supermajority had poor git hygiene and security practices such as this.

Don’t become a Supply Chain Attack vendor

Metal Toad is surrounded by third party vendors in our work with clients, and we ourselves are a third party vendor. I'm constantly paranoid that we ourselves could become the weak link in the chain. Below are some actions we take and all vendors should take too, to avoid becoming a vector.

• Define a role and appoint an individual who is explicitly accountable for assessing vulnerabilities in the supply chain and build/deploy cycle.
• Establish a methodology to create automated and tailored scanning of the SDLC toolchain (such as upon every pull request and every merge).
• Scan for hard coded passwords and other security threads on every major event during a build/deploy cycle (most static code analysis tools do this).
• Ensure all credentials are stored in a separate vault system, such as AWS Secrets Manager
• Ban the use of username/password credentials, and enforce at minimum the use of keys.  Scan and audit this enforcement regularly.
• Strictly scan and monitor, with both technology and human labor, often and obsessively, the security of servers used to distribute builds to customers.

Metal Toad offers a variety of rapid threat assessments, code audits, and management feedback offerings to assist our clients with improving their security and resilience  position. Please reach out today to learn more.

Image by Wikipedia.org