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

David Cottingham

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:

Executable Name Product Name
AcroCEF.exe  
SingleClientServicesUpdater.exe  
WCChromeNativeMessagingHost.exe Adobe Create PDF
32BitMAPIBroker.exe Adobe Acrobat 32BitMAPIBroker
64BitMAPIBroker.exe Adobe Acrobat 64BitMAPIBroker
FullTrustNotifier.exe  
Acrobat.exe Adobe Acrobat DC
Acrobat.exe Adobe Acrobat DC
AcrobatInfo.exe Adobe Acrobat DC
acrobat_sl.exe Adobe Acrobat
AcroBroker.exe Adobe PDF Broker Process for Internet Explorer
AcroTextExtractor.exe Adobe Acrobat text extractor for non-PDF files
ADelRCP.exe ADelRCP Dynamic Link Library
AdobeCollabSync.exe  
CRLogTransport.exe CRLogTransport Application
CRWindowsClientService.exe Adobe Crash Reporter Service
Eula.exe EULA
LogTransport2.exe LogTransport Application

                              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’:

Application Library Name Product Name
chrome_elf.dll Chromium
icudt.dll International Components for Unicode
libcef.dll Chromium Embedded Framework (CEF) Dynamic Link Library
nppdf32.dll Adobe Acrobat
nppdf32.dll Adobe Acrobat
Acrobat32OL.dll  
Onix32.dll Onix
ACE.dll ACE 2020/12/23-20:41:48
AdobeXMP.dll Adobe XMP Core 2020/06/15-10:20:05
AGM.dll AGM 2020/12/23-20:41:48
AIDE.dll AIDE 2020/08/13-20:41:23
BIB.dll BIB 2020/12/23-20:41:48
BIBUtils.dll BIBUtils 2020/12/23-20:41:48
CoolType.dll CoolType 2020/12/23-20:41:48
JP2KLib.dll JP2KLib 2021/01/15-07:39:31
A3DUtils.dll 3D Utilities Library
ACE.dll ACE 2020/12/23-20:41:48
Acrobat.dll Adobe Acrobat DC
AcrobatRes.dll Adobe Acrobat DC
adobeafp.dll Adobe Acrobat File Preview
AdobeLinguis…  Adobe Linguisitc Library
AdobeXMP.dll Adobe XMP Core 2020/06/15-10:20:05
AGM.dll AGM 2020/12/23-20:41:48
ahclient.dll AdobeHelp Dynamic Link Library
AIDE.dll AIDE 2020/08/13-20:41:23
ANCUtility.dll Adobe Acrobat
AXE8SharedEx…  AXE8SharedExpat 2020/12/23-09:04:30
AXSLE.dll AXSLE 2020/06/16-12:37:28
BIB.dll BIB 2020/12/23-20:41:48
BIBUtils.dll BIBUtils 2020/12/23-20:41:48
ccme_asym.dll RSA BSAFE Crypto-C ME
ccme_base.dll RSA BSAFE Crypto-C ME
ccme_base_no…  RSA BSAFE Crypto-C ME
ccme_ecc.dll RSA BSAFE Crypto-C ME
CoolType.dll CoolType 2020/12/23-20:41:48
CRClient.dll Adobe Crash Reporter Client DLL
cryptocme.dll RSA BSAFE Crypto-C ME
DirectInk.dll DirectInk
ExtendScript…  ExtendScript 2019/07/29-10:07:31
icucnv58.dll  
icucnv67.dll International Components for Unicode
icudt58.dll  
icudt67.dll International Components for Unicode
icuuc58.dll  
icuuc67.dll International Components for Unicode
JP2KLib.dll JP2KLib 2021/01/15-07:39:31
logsession.dll LogSession
PDFPrevHndlr…  Adobe PDF Preview Handler
pe.dll PE
ReaderUC.dll  
rt3d.dll 3D Runtime Dynamic Link Library
ScCore.dll ScCore 2019/07/29-10:07:31
sqlite.dll sqlite Dynamic Link Library
ViewerPS.dll Acrobat Viewer ProxyStub Library

                             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.

Airlock's Opinion on ISM Control 1471

               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.

 

Request a Demo