Securing software products—protecting the supply chain

Earlier this year, I presented sessions at SHARE New Orleans on mainframe security, hacking, and security assessments. These spiked quite a bit of interest among attendees. In particular, a conversation kicked off with several leading mainframe-focused software developers. They told me they were looking to assess the security controls of their z/OS based development environments as they wanted them to be demonstrably watertight.

This is sound thinking. Attacks on the software supply chain are becoming more prevalent and more sophisticated. In its report Top Trends in Cybersecurity 2022, Gartner®  identified a need to anticipate the expansion of the enterprise ‘attack surface’ and so “increase investment in processes and tools for identity threat detection and remediation and digital supply chain integrity.”

Gartner reported that “highly connected supply chains and use of cyber-physical systems have exposed new and challenging attack ‘surfaces’,” and predicted that, by 2025, 45% of organizations globally will have experienced attacks on their software supply chains. “Security and risk management leaders need to partner with other departments to prioritize digital supply chain risk and put pressure on suppliers to demonstrate security best practices.”

Securing all software development components, activities and practices

The software supply chain encompasses everything influencing or playing a role in a product or application during its entire software development life cycle (SDLC). It’s more important than ever to secure all components, activities, and SDLC practices involved in the creation and deployment of software. Development teams and vendors must ensure they only utilize code components that are free from known vulnerabilities, find ways to validate the integrity of their build, and check for unauthorized tampering.

And if you don’t get it right, the implications can be huge. Remember the SolarWinds Orion supply chain compromise, which came to light in December 2020? Suspected nation-state hackers identified by Microsoft as a group known as Nobelium gained access using compromised credentials and a third-party application that took advantage of a zero-day vulnerability. Around 33,000 public and private organizations used the Orion network management system to manage their IT resources.

It’s believed the hackers first tested their ability to insert malicious backdoor malware into Orion software as early as October 2019. SolarWinds’ CEO later confirmed that “suspicious activity” in his Office 365 email account allowed the bad actors to access and exploit the software development environment. 

This was a big deal. Especially for the US federal agencies affected, which included the FBI and the Pentagon, and up to 18,000 other SolarWinds customers attacked with malware. Systems were monitored, data and IP were harvested. This impact was unprecedented, leading to the hack being described as “the largest and most sophisticated attack the world has ever seen.” It was also reported that around one-third of the victims had no direct connection to SolarWinds. The ramifications spread far and wide. 

No-one is exempt. Every system, every organization, is in the hacker’s sights. A couple of months ago, for example, we learned that “IBM’s use of Progress Software’s compromised MOVEit application appears to have resulted in the unauthorized access of millions of people’s health care information” held by two US state agencies. With this particular data breach, it was reported that CL0P, a Russian-speaking cybercriminal group, had exploited a critical vulnerability in the widely-used MOVEit file transfer software to breach dozens of organization. They included the US Department of Energy, British Airways, pension funds, and many more.

No compromise: product pen testing

Since Solar Winds, it’s become more commonplace for z/OS based software vendors to have their development environments checked and assessed by mainframe specialists, who look at their deployed security controls, and SDLC. We’re asked to do this on a regular basis. Indeed, as I told the folk at SHARE, a security assessment by experts including a review of SDLC processes and controls is a great way to understand the effectiveness of your security controls.

As part of this process, product penetration testing from a trusted provider can give ISVs and end users the assurances they need that their products are secure. This should include checking for vulnerabilities, scanning source code, reviewing installation and customization documents, and reviewing architecture documents – to reveal vulnerability and configuration issues, and other potential routes for cyberattack. In today’s escalating threat landscape, generating a Software Bill of Materials (SBOM) has also become an important building block in software security and software supply chain risk management. This is a nested inventory, a list of ingredients that make up software components. 

In short, we need to scrutinize vendor software products (and the SDLC) using the tools and eyes of a hacker—to help ensure software products are not the weak links in the chain. 

For more information and resources about the Pen Testing process, visit https://vertali.com/security/product-penetration-testing/