3 Takeaways from Sandworm Hacker Group’s Indictment 

The U.S.Department of Justice officially revealed in October what it said were a number of instances of Russian government-sponsored hacking when it formally indicated six members and officers in Russia’s military agency Russian Main Intelligence Directorate (GRU). In addition to naming the members of the hacker group, it was also the first time the U.S. government charged the alleged perpetrators behind the Sandworm attacks in a court of law. These attacks crippled infrastructure worldwide, including targets in the U.S., and caused several billion dollars in damages.

The indictment listed the following incidents the alleged perpetrators either conspired to or directly initiate through the release of malware and direct network attacks: Ukrainian government and critical infrastructure; the 2017 French elections; worldwide businesses and critical infrastructure with NotPetya malware, including hospitals and other medical-related infrastructure in Pennsylvania; the FedEx subsidiary TNT Express B.V; an unnamed U.S. pharmaceutical maker; the 2017 PyeongChang Winter Olympics hosts, participants, partners and attendees; the Novichok poisoning investigations by the Organisation for the Prohibition of Chemical Weapons (OPCW) and the UK’s Defence Science and Technology Laboratory (DSTL); and various companies and governments in the country of Georgia.

All told, U.S. prosecutors estimated the losses stemming from the U.S. drug company attack by Sandworm alone totaled $1 billion, while writer Andy Greenberg disclosed the Sandworm hacker group-created NotPetya malware alone caused over $10 billion in damage in an article in Wired, which a senior U.S. official subsequently confirmed publicly.

“No country has weaponized its cyber capabilities as maliciously or irresponsibly as Russia, wantonly causing unprecedented damage to pursue small tactical advantages and to satisfy fits of spite,” said Assistant Attorney General for National Security John C. Demers in a statement. “Today the department has charged these Russian officers with conducting the most disruptive and destructive series of computer attacks ever attributed to a single group, including by unleashing the NotPetya malware. No nation will recapture greatness while behaving in this way.”

But while the indictments—issued just days before the U.S. presidential election—are the first of their kinds, the information the indictment reveals, as well as other information about Sandworm and other Russian government-sponsored attacks that have been revealed during the past few years, underscores how IT infrastructures can remain very exposed.

Meanwhile, amid these ongoing often brazen attacks on network infrastructure, there are steps and processes DevSecOps teams can implement to help mitigate the threat—that is, to a certain extent.

The Government Is Not Protecting You

The indictments do serve as a way for the U.S. government to send a message to the Russian government that it might plan to take a stronger defense against these types of attacks. And yet, the indictments also continue to expose how the U.S. government has continued to allow gaping security holes and threats to remain unchecked, despite its purported crackdown.

It has been widely reported that the U.S. government, under both President Obama’s and President Trump’s presidencies, for example, have known of these and other attacks and chose not to take action in many cases—including for malware created by the National Security Agency (NSA) and other U.S. government agencies. The government, for example, had failed to adequately issue patches for Stuxnet—which is widely believed to have been created by U.S. and Israeli hacker teams—as well as reversed-engineered variants of Stuxnet. Knowing of these and other security holes created by malware campaigns introduced during these covert cyber battles, the U.S. government has thus often failed to provide warnings and patches for U.S.-based IT groups to patch their networks in the name of national defense interests, according to Greenberg’s reporting in his book, “Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin’s Most Dangerous Hackers.”

“After all, the hackers who had dug up the four zero-day vulnerabilities used in Stuxnet hadn’t reported them to Microsoft so that they could be patched for other users. Instead, they had exploited them in secret and left Windows machines around the world vulnerable to the same techniques that had allowed them to infiltrate Natanz [in Iran where Stuxnet crippled a nuclear facility’s operations],” Greenberg wrote. “When the NSA chose to let its Tailored Access Operations hackers abuse those software  flaws, it prioritized military offense over civilian defense.”

Since the U.S. government—and certainly not the Russian government—cannot be counted on to communicate vulnerabilities and issue patches, the DevSecOps community is thus left up to itself to mitigate and thwart the threat government-sponsored malware poses the best way they can.

“While the government releases bulletins and advisories related to the current threat landscape, it is not their responsibility to release necessary patches for vulnerable hardware or software components,” said Kacey Clark, threat research team lead at Digital Shadows. “The burden of releasing patches and notifying consumers should lie with the respective entities that built, developed, or distributed the product. Additionally, it is the consumers’ responsibility to apply necessary patches as they are released and in accordance with their patch management policy. Organizations should prioritize patching based on the impact a vulnerability has on organization data, the types of systems that are impacted, the number of systems that are affected, the access level required to exploit the vulnerability, and how widely known the vulnerability is.”

Think Damage Control

For Sandworm’s documented denial of service (DoS) attacks on hospitals, shipping conglomerates and other organizations, simple backups of data to media not connected to the network could have better prepared the victim organizations against the attacks by relying on damage control and planning—this could have thus prevented hundreds of millions of dollars and over a billion dollars in damage in at least one case mentioned above. If the organizations had regularly backed up most of their data the old fashioned way on tapes, for example, say at least once a week, the malware may have not been able to penetrate what was stored.

“Having backups is a good IT hygiene practice because many times a DoS attack attracts the security team’s attention to a particular area of the environment, making it easier for the attacker to carry out their objective of stealing data, deploy malware, etc. in another area of the environment. So, in that scenario having easily accessed backups can minimize downtime,” said Stephen Salinas, head of product marketing at Deep Instinct.

Direct Action to Take Now

As implied above, installing patches can only protect your data to a certain degree. The unfortunate truth, as DevSecOps teams know, is that many vulnerabilities across networks often remain unpatched, without taking into account the vulnerabilities for which patches are not disclosed, including state-sponsored malware from the U.S. and other governments might have created (also described above). According to a recent Enterprise Strategy Group report, which software security firm Snyk commissioned, only 30% of the respondents said their organization was able to protect more than 75% of their code for the next 12 months, for example.

A key takeaway is that DevSecOps teams must put into place damage control processes. Chaos engineering, which is similar to a fire drill, for example, can help as well when DevSecOps teams respond to a practice network attack.

“At their core, the majority of these exploit campaigns carried out by hacking groups like Sandworm focus on the time it takes most organizations to detect and remediate the vulnerabilities targeted as part of these attacks. In order to protect themselves, DevOps and DevSecOps teams need to understand that there are technologies that can help them respond more quickly and effectively to these sorts of attacks – particularly cloud-native technologies that provide visibility into IT assets, their dependencies and relationships, and where they are deployed,” said Ali Golshan, co-founder and CTO at StackRox. “The exposure and risk of vulnerabilities is the main advantage in these attacks, especially since stateful applications are extremely difficult to detect and patch. Leveraging containers, immutable, and ephemeral infrastructure ensures time to remediation and the impact on mission-critical systems is as low as possible.”

Featured eBook
The Dangers of Open Source Software and Best Practices for Securing Code

The Dangers of Open Source Software and Best Practices for Securing Code

More and more organizations are incorporating open source software into their development pipelines. After all, embracing open source products such as operating systems, code libraries, software and applications can reduce costs, introduce additional flexibility and help to accelerate delivery. Yet, open source software can introduce additional concerns into the development process—namely, security. Unlike commercial, or ... Read More
Security Boulevard

B. Cameron Gain

B. Cameron Gain first began writing about technology when he hacked the Commodore 64 family computer in the early 1980s and documented his exploit. Since his misspent youth, he has put his obsession with software development to better use by writing thousands of papers, manuals, and articles for both online and print. His byline has appeared in Wired, PCWorld, Technology Review, Popular Science, EEtimes, and numerous other media outlets.

b-cameron-gain has 6 posts and counting.See all posts by b-cameron-gain