The Aussie govt should be applauded for the ambitious goal of Australia becoming “the world’s most cyber-secure country by 2030.” By borrowing good ideas and newly introduced regulatory frameworks from other govts, Australia could potentially get there even quicker.
Basically, the Australian government has the unique benefit of learning from what other national governments have already achieved in the past couple of years and building upon those frameworks and regulations to meet the 2030 goal. After a number of data breaches that were clearly linked back to open source, application or API vulnerabilities, many govt regulators around the world have woken up to the importance of application security.
In response, govt regulators have moved away from high-level guidance to prescriptive regulations, reflecting global best practices, to ensure companies achieve the effective application security needed in the modern age. More so, as govts are typically very large clients of software and apps, with the clout to drive better application security adoption.
What are the trends the Aussie gov’t could build on?
They are using their procurement process to mandate and lead better security by ensuring their own suppliers are providing evidence of best practice application security as a part of doing govt business. Three trends the Aussie govt could build upon to meet the 2030 goal:
- Prescriptive API and specific Application Security regulations to give regulated enterprises ‘step by step’ guidance on what controls are expected to form best practices.
- “Putting your money where your mouth is” and using government procurement processes to mandate adoption of best practices in application security amongst suppliers.
- Focus on total supply chains and the need to understand partners and suppliers.
The good news is that Aussie enterprises can get on the front-foot and automate pretty much every best practice application security trend right now, without waiting for prescriptive regulations from the govt. The tools, techniques and managed services exist in Australia to make all of the recommended controls simple, cost-effective, and fully automated.
What are some examples we can learn and adapt from?
Philippines Central Bank prescribing best practice API security controls
After noticing a string of high-profile data breaches relating to application programming interfaces (API) in 2022, the Bangko Sentral ng Pilipinas (BSP) released Memorandum No. M-2022-016 for API security controls. It prescribes a range of cybersecurity practices for Filipino banks and non-banks’ alike who utilise APIs and any interconnected platforms.
This is particularly important as Filipino banks are undergoing massive digital transformation programs and they are releasing innovative banking platforms that rely on APIs for enhanced customer experiences. BSP-supervised financial institutions (BSFIs) need to adopt a range of security controls under Memorandum No. M-2022-016, including but not limited to:
- Maintaining an up-to-date API inventory;
- Proactively managing API versions and unintentional endpoint exposure;
- Conduct regular security tests using API and business logic exploits such as, but not limited to: SQL injection, replay attacks, and logic bypass; and enforce thresholds and rate-limiting API calls to prevent distributed denial-of-service (DDoS) attacks and others;
- Ensure that sensitive API payload data is encrypted using industry accepted encryption standards and versions.
The Australian government could definitely leverage something similar to BSP Memorandum No. M-2022-016 to drive better API security. This is especially important given what we know so far about the high profile Optus and Medibank breaches. In the meantime, Australian organisations can already improve and automate their own API security today, such as:
- Conducting an “Attack Surface Discovery” exercise to ensure all publicly exposed APIs are correctly captured in organisational asset registries.
- Implementing Interactive Application Security Testing (IAST) technologies such as Seeker, that will automatically detect vulnerabilities as developers and engineers are writing and testing new APIs.
- Leveraging Dynamic Application Security Testing (DAST) delivered as a continuous Managed Service such as White Hat, to continuously monitor APIs exposed in production web applications.
- Leveraging platforms such as Code Dx, that de-duplicate and correlate all manual penetration testing results, risk assessments, threat models and automated scans from 170 plus tools into a central dashboard to provide a prioritised risk posture by application, project or platform.
U.S. Federal Govt requirement to produce a Software Bill of Materials
Another good example is the US Presidential Executive Order 14028 which, amongst many other security controls, mandates the need for a complete Software Bill of Materials (SBOM) be produced and automatically maintained as a part of suppling software to the federal govt.
The US gov’t is one of the largest software client, and nothing forces positive security changes quicker than a huge client insisting on evidence that, all open source components and interdependencies are correctly documented and updated as changes are made.
The mandate for an SBOM came about because the use of outdated or vulnerable open source components has been linked to high profile data-breaches globally. The latest Open Source Security & Risk Analysis (OSSRA) report demonstrated the scale of the problem and the reasons why open source component security was a cornerstone of the executive order.
Synopsys’ study examined anonymised findings from over 2,400 commercial codebases across 17 industries and cross-referenced it with their Black Duck Knowledge-Base to compose the OSSRA report. The Black Duck Knowledge-Base contains information for nearly 200 million versions of over 5.1 million open source components leverages data from more than 26,000 unique sources. Some of the highlights from the OSSRA report showed that:
- 97% of all customer applications include open source code components;
- 81% of all codebases contain at least one known open source vulnerability;
- 88% of codebases that contained open source code has not updated components for over 2 years.
The Australian Government are also massive customers for applications and software and a similar mandate or recommendation for an SBOM to supply to government could be another stepping stone to Australia becoming “the world’s most cyber-secure country by 2030.” Aussie firms serious about open source component vulnerability management can use tools like Black Duck to automatically produce an SBOM in accordance with industry standards.
Singapore’s updated regulations on supply chain risk
Monetary Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines have been a bedrock of risk management for Financial Institutions (FIs) not only in Singapore, but across South East Asia. The revision of the TRM guidelines focused on addressing the cyber concerns of FIs, considering the usage of cloud technologies, application programming interfaces, rapid software development, and increasing reliance on third-party vendors.
There are a number of clauses in the recent updates to TRM guidelines in relation to third-party vendor risk management. They are good practices that can easily apply to any firm. Like the US Executive Order 14028, the emphasis is on-going and continuous assessment, not just once-off checks. The 4 new clauses relevant to application security include:
3.4.3: On having high standards of care and diligence
Management of third-party vendors is an ongoing process. A one-off selection exercise done in the past does not automatically make the selected vendor eligible for future partnerships. FIs should regularly review and audit vendors to ensure that data is protected continuously.
6.13 On open-source software codes from third parties
Review and test third-party and open-source software codes before any integration. FIs should implement best practices including Secure Coding, Source Code Review, and Application Security Testing. Rather than having new policies and procedures, FIs can simply include third-party and open-source software as part of existing best practice policies.
6.1.4 On timely vulnerability remediation
Remediate all software vulnerabilities — third-party or in-house — in a timely manner using a robust vulnerability management policy or procedure that prioritises the fixing of these vulnerabilities by severity and data sensitivity. Also, your third-party vendors and you should have an open-door policy for reporting new vulnerabilities at any time. If you use open-source applications, keep an active lookout for vulnerabilities reported by the community.
6.4.2 On vetting third parties
Develop a comprehensive checklist when it comes to reviewing third-party vendors. How is the vendor’s Data Privacy posture? Does it have relevant certifications like SOC2, ISO 27001, or Trustmark? Be diligent on vendor selection with this holistic approach encompassing both business and information security deciding factors to help assess suitability.
As with the other trends, the Australian government could use elements of the Singapore MAS TRM to provide prescriptive guidance to Australian businesses. The government’s ambitious goal of Australia becoming “the world’s most cyber-secure country by 2030” is achievable and by learning from others we may be able to get there quicker.
Phillip Ivancic is the Head of Solutions Strategy for APAC at Synopsys.
