Leveling Up: How to Improve Your ACSC Recommended Maturity Model

April 06, 2020 By Cameron Townshend

4 minute read time

The Australian Cyber Security Center (ACSC), under the direction of the Australian Signals Directorate (ASD), offers security advice to protect national infrastructure. DevSecOps practitioners in the private sector, as well as state and territory governments, are encouraged to quantify their current cyber security maturity status and consider plans that transform their organizations to higher levels. 

"Now is a good time for businesses to be more aggressive in blocking potentially malicious emails and websites from their network gateway. Now more than ever, it is critical that businesses have their software patched and up to date," says ACSC acting Head, Karl Henmore.

The ACSC suggested three maturity model levels. Every level has specific remediation strategies, each designed to reinforce and strengthen one another. The most effective of these mitigation strategy benchmarks is known as the Essential Eight.

All maturity models include recommendations to patch or update applications as seen here. Note how Level One recommendations remediate vulnerabilities within one month, while more advanced, Level Three organizations make fixes within 48 hours. Is there a better way? In a word: yes.

ACSC Mitigation Strategy: Patch or Update Applications

Here are ACSC's three maturity levels, with emphasis added. 

Maturity Level One

Security vulnerabilities in applications and drivers assessed as extreme risk are patched, updated or mitigated within one month of the security vulnerabilities being identified by vendors, independent third parties, system managers or users.

Applications that are no longer supported by vendors with patches or updates for security vulnerabilities are updated or replaced with vendor-supported versions.

Maturity Level Two

Security vulnerabilities in applications and drivers assessed as extreme risk are patched, updated or mitigated within two weeks of the security vulnerabilities being identified by vendors, independent third parties, system managers or users.

Applications that are no longer supported by vendors with patches or updates for security vulnerabilities are updated or replaced with vendor-supported versions.

Maturity Level Three

Security vulnerabilities in applications and drivers assessed as extreme risk are patched, updated or mitigated within 48 hours of the security vulnerabilities being identified by vendors, independent third parties, system managers or users.

An automated mechanism is used to confirm and record that deployed application and driver patches or updates have been installed, applied successfully and remain in place.

Applications that are no longer supported by vendors with patches or updates for security vulnerabilities are updated or replaced with vendor-supported versions.

Level Up Your Maturity Model Using the Sonatype Nexus Platform

Software teams can increase their cyber security maturity levels, starting today. By automating open source policies earlier in their development practices, teams can remediate problems while meeting - and even exceeding - the ACSC Level 3 requirement - within 48 hours. 

Rather than updating vulnerable open source software components after the fact, we enable more robust security practices to be introduced early on, dramatically increasing security. Strategies include:

Blockade -- Block vulnerable components from entering your software development life cycle (SDLC). This is made possible by carefully calibrating automated policies to block open source components being downloaded by developers or build systems based on known vulnerabilities and/or license restrictions. Our tool for this is called Nexus Firewall

Identification -- Identify, inventory, and monitor every open source component inside an application, now and over time. Our tool for this is called Nexus Lifecycle. This gives you an always up-to-date SBOM (Software Bill of Materials) to stay abreast of changes in open source components and their dependencies.

TIP: Generate an SBOM here, for free, to see what components are inside your application right now.

Automation -- Both of these solutions automate open source governance across every stage of the SDLC. With a flexible policy engine that performs different enforcement actions by stage and application type, both identification and blockade strategies are automated, greatly enhancing the speed with which one can mitigate problems. 

Deluge of Open Source Software Components

At Sonatype we are hyper-focused on identifying and remediating vulnerabilities in open source software components across the SDLC. There is an enormous volume of open source software components in use today, as detailed in our 2019 State of the Software Supply Chain report. Our platform helps DevSecOps practitioners automate open source policies and enforce security practices from the start while not adding a time-consuming “security tax” on development efforts.

Get started today by analyzing your application and reviewing the automated report of what is inside it.

Tags: devsecops, maturity model, featured, DevSecOps Maturity model

Written by Cameron Townshend

Cameron Townshend Bsc, MSysDev, MCP CP Snr, MCSD - has extensive experience building large mission critical applications. Developed the WeatherChannel.com.au website and backend integration. This site won 2010 Kentico site of the year for Integration and 2011 Astra award for Most Outstanding Use of Technology. Initial project lead on NSW Biosecurity Information System. He is both a hands-on developer and a skilled communicator and leader of project teams.