Essential Eight and Legacy Systems
In the many discussions I’ve had with our agency customers around their efforts to implement Essential Eight security, the most common obstacle encountered is deploying the strategies on the legacy systems remaining in their environments.
By ‘legacy’ I mean those applications and operating systems that are reaching or at ‘End-of-Life’, limiting their ability to be upgraded. Think Windows Server 2008 or 2012 and Java Runtime Environment.
As these systems often still play a vital role in the organisations they support, they can’t be decommissioned and the technical debt makes it difficult to migrate them to newer platforms, including cloud.
The legacy system challenge is not just limited to the people I’ve spoken with. According to the latest Commonwealth Cyber Security Posture Report, 69% of the agencies with legacy technology in their networks indicated that it had impacted their ability to fully implement the Essential Eight.
Though they present obstacles to deploying most of the eight strategies, the most common are application and operating system patching.
Recognising the challenges posed by legacy systems, the ASD advises in the Essential Eight Maturity Model FAQ that ‘It is often difficult to implement the Essential Eight, either in part or in full, on legacy systems. In such cases, ASD strongly encourages organisations to upgrade their legacy systems as a priority so that the Essential Eight can be implemented in full. While a system is in the process of being upgraded, organisations should implement compensating controls where possible to do so.’
Many organisations ‘carve out’ these systems from assessment through an exception process. However, unless these systems operate in a completely ‘air-gapped’ environment, not applying these Essential 8 cyber security strategies mean they remain a weak link in your cyber defences.
The ASD advises organisations to minimise exceptions, recommending instead to manage the residual risk by implementing compensating controls and reducing the number of systems or users impacted.
Compensating controls aim to mitigate the same risk as the Essential Eight mitigation it is replacing. It should not be seen as an alternative to the Essential Eight security controls which reflect the ASD’s expertise and experience.
From an assessor’s perspective, a compensating control that mitigates the specific risk to a similar degree as the original Essential Eight control can be assessed as ‘Implemented’.
To understand what a compensating control looks like, let’s use the Essential Eight Patch Applications strategy as an example. Application Patching mitigates known vulnerabilities being exploited [T1190] by ensuring that the vendor supplied patches are applied as soon as possible after they are released.
When a vulnerability is detected in an End-Of-Life or otherwise unsupported application, there’s not always a patch provided to apply.
For a legacy web application, a suitable compensating control would be to deploy an application protection that includes Virtual Patching. It mitigates the risk of an exploit by analysing all web traffic to identify and block any exploit patterns. As with real patching, the virtual patch is applied as soon as possible after the vulnerability is identified.
If the time between identification and patching is within the applicable Essential Eight Maturity Level metrics (e.g. 48 hours for critical patches on internet facing systems), the legacy platform can be assessed as ‘implemented’ for that control. Not only that, but the threat posture of that platform has been significantly improved.
If we can be of cyber security service assistance we’re always happy to chat. Get in touch with us or by using the form below.
