Undetected and Dormant: Managing Australia’s Software Security Threat

The executive order directs the US Office of Management and Budget to take appropriate steps to require that agencies comply with the guidelines within 30 days. This means that federal agencies must begin adopting the framework and related guidance immediately while customizing it to their agency-specific risk profile and mission. Vendors that supply software to the US government will soon also have to attest to meeting these guidelines.

In the Australian context, however, software supply chain risks remain largely underappreciated and unaddressed. So, what two key things could the Australian government do to manage these risks?

First, it should update government procurement policies and processes to manage software supply chain risks.

The government should ensure that there are adequate mechanisms to assess software supply chain risks early in the acquisition or procurement process. At the later stages of the acquisition process, which in some cases can be years later, a supply chain risk may be realized and the government may be overly committed to the solution of choice—forcing it to either pay significant costs to remove the risk or attempt to manage the risk. Strengthening references to the importance of software supply chain risks in key procurement policies would support the government to make more informed purchasing decisions and embed risk management practices at the early stages of the acquisition process.

In particular, the government should consider adopting the US guidelines and integrate them into its procurement policies and practices. These documents are intended to help government agencies get the necessary information from software producers in a form that can help guide risk-based decisions. The recommendations span many types of software, along with firmware, operating systems, applications and application services, among other things.

Procurement processes should include asking software companies about their product integrity practices. This could include key questions about their internal processes and oversight mechanisms to mitigate the risk of modification during the development lifecycle and whether they undertake third-party testing to ensure that security vulnerabilities are identified earlier in the process?

The government should also take steps to protect source code integrity by understanding whether vendors have shared their unique intellectual property as a condition of market access. Increasingly, we have seen instances of countries implementing new requirements—most notably, mandates to review or even hold source code—as a condition to sell technology to certain parts of their market. Widespread source code disclosure, however, could actually weaken security, since source code can be leveraged to detect and exploit vulnerabilities in software used by organizations globally. Currently, the Australian government doesn’t have visibility as to whether companies it deals with have shared their source code with foreign governments—posing a potential security risk.

Procurement policies should be amended to identify the companies that have shared the source code of their unique intellectual property with governments as a condition of access to certain markets. A similar approach is being taken by the US government.

Second, the Australian government should establish practices and procedures to regularly review business-critical software.

While some organizations might look at how a company manages its software supply chain at the point of purchase, few would undertake regular and continuous reviews of these practices. However, as we have seen from global attacks, regular reviews of key software companies—their culture and software development practices—may be helpful in preventing exposure to supply chain attacks.

As part of this review process, the government could collaborate with vendors of critical software on risk-based principles, including relevant changes to their software development practices or key  personnel changes (for example, the chief security officer leaving the organization). It should also consider the ‘red line’ for removing software from its environment—in other words, at what point or risk level would an agency reconsider having a particular software product, and who can sign off on removing it?

As our world becomes increasingly digitized and connected, attacks on software supply chains are only set to increase. Compromising them can be an effective technique to gain widespread and undetected access to networks and systems. These risks are particularly acute for the defense and national security communities, which depend on software for key functions such as surveillance, data analytics and weapon systems, most of which is developed in the private sector.

Sarah Sloan is head of government affairs and public policy for Australia and New Zealand at Palo Alto Networks.This article is published courtesy of the Australian Strategic Policy Institute (ASPI).