Opinion: Why the ISM Control ‘1471’ Is Impractical for Allowlisting

Opinion: Why the Information Security Manual (ISM) Control ‘1471’ Isn’t Practical for Allowlisting at Scale

TLDR; Take a look at the tables containing Product Names for Adobe Acrobat DC in this article, the variations in product names are staggering.

Overview

At Airlock Digital, we often hear from new and existing Australian customers regarding the Australian Government Information Security Manual (ISM) control 1471. In particular, customers ask how they can achieve compliance with this control using the Airlock allowlisting platform.

The control was first introduced in 2019 and reads as follows:

Security Control: 1471; Revision: 2; Updated: Apr-20; Applicability: O, P, S, TS
When implementing application control using publisher certificate rules, both publisher names and product names are used.
Source: https://www.cyber.gov.au/acsc/view-all-content/ism

This article will describe the practicality of allowlisting using this rule type at scale. Allowlisting is the process of choosing which files you trust and blocking everything else on an endpoint. 

The Intent

The intent of this control is clear, ensure companies are reducing the attack surface of publisher rules by tying them to specific products. This does two things:

• Ensures that administrators are only allowing specific applications rather than trusting any file a company digitally signs; and
• Reduces the attack surface when a certificate compromise at a software vendor occurs, constraining the ability for an attacker to run signed malicious code in an environment (unless the attacker knows the customers ruleset of course).

Sounds straightforward right? Ultimately it is good security advice. However, in reality, practical implementation and management of this control is near impossible in dynamic computing environments (any environment with users), regardless of the allowlisting technology used.

The working example I’m going to use in this article is a fairly common one. Let’s say the organisation wants to allow Acrobat Reader DC, on the surface it would seem as simple as trusting ‘Adobe Inc’ as the publisher and then ‘Acrobat Reader DC’ as the product name.

The Data
Let’s take a look at the files that make up an Acrobat Reader DC installation. Executable files in the application are all signed by the publisher ‘Adobe Inc.’, which is a great start. The following table displays all executable files with their associated product names:

                              Table 1: Acrobat Reader DC Executable Product Names

Let’s now take a look at application library names, keeping in mind that all listed files are signed by ‘Adobe Inc’:

                             Table 2: Acrobat Reader DC Application LibraryProduct Names

Looking at the tables above, you can start to see the scale of the challenge due to the significant variation in product names across files.

The Challenges

Challenge One: Software is nearly always more than a single executable file

Software comes in many shapes and sizes and is nearly always composed of multiple executable files and application libraries (.dll’s). Additionally, third party software is bundled within software which can be seen above, with Chromium dll’s shipped with Adobe Acrobat DC and signed by Adobe Inc.

This may be manageable when allowlisting executable files only (I’m looking at you default AppLocker deployments). However, if a customer intends on achieving Maturity Level Two or greater for application control on the ACSC Essential eight maturity model, the sheer number of files and application libraries that need to be handled to allow a single product to run can be overwhelming.

In order to allow Acrobat Reader DC via product names:

• 13 rules would be required for executables; and
• 45 rules would be required for application libraries.

This could be cut down with creative wildcarding, however if you are allowing the product name ‘*Adobe*’ it defeats the purpose of the ISM control 1471 in the first instance.

Challenge Two: The Product Name field can be blank

As you can see from the above files, many of them contain a blank Product Name field as it is an optional entry for developers at the time of software compilation. This makes the original ISM rule impossible to apply on these files and they effectively require an exemption.

Challenge Three: Scale and Maturity

Extrapolating the above data out, it is easy to see how the scale of rules required is staggering. Additionally, maintaining this ruleset through application updates (note that Adobe uses compilation dates in a number of files above) makes management near impossible, regardless of the technology used even with automated and slick product workflows.

Proposed Compensating Control

So if this isn’t practical? What can be done to achieve the intent of the control?

Combining Publisher and Path rules is an alternative and has the following benefits:

• Typically only one or two rules are required per application, as applications are often located in static paths;
• Applications are easier to identify and group by paths and avoids the confusion of trusting ‘Chromium’ signed by ‘Adobe Inc.’ as shown in Table 2 above;
• The ability for an attacker to execute code in an environment with a stolen code signing certificate is still reduced as signed malware must be dropped in the relevant directories.

Airlock Digital appreciates the guidance ACSC provides with the ISM, which continues to drive the maturity uplift of organisations. Proposing the above compensating control is not intended to water down the security requirements of 1471, it’s simply an alternative to customers not being able to comply due to administrative overhead.

Airlock Recommendations

Organisations can use the Airlock Blocklisting rule engine to achieve compliance with this control. In the event organisations are struggling to comply due to management overhead, Airlock recommends customers consider the implementation of publishers and path rules as an alternative.

Each organisation should use a risk based approach when assessing if this alternative is right for them.

               Fig 1: The Edit Blocklist Metadata Rule Window                

Shown in the Window above is a rule that applies to any file containing ‘Adobe Inc’ as a publisher and is not part of the default ‘Acrobat DC’ folder path. Since Blocklisting is a negative match, files that are signed by Adobe Inc and are located outside of this folder path will be blocked.